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Foreword 



rd , 



This Technical Report has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document is a technical specification of the overall support of Multimedia Broadcast Multicast Service in 
UTRA. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

[I] 3GPP TR 21.905: " Vocabulary for 3GPP Specifications ". 

[2] 3GPP TS 22.146: "Multimedia Broadcast/Multicast Service; Stage 1". 

[3] 3GPPTS 22.246: "MBMS User Services; Stage 1". 

[4] 3GPP TS 23.246: "Multimedia Broadcast Multicast Service; Architecture and Functional Description". 

[5] 3GPP TR 25.992: "Multimedia Broadcast Multicast Service (MBMS); UTRAN/GERAN Requirements". 

[6] 3GPP TS 23.236: "Intra-domain connection of Radio Access Network (RAN) nodes to multiple Core Network 
(CN) nodes". 

[7] 3GPP TS 33.246: "3G Security; Security of Multimedia Broadcast/Multicast Service (MBMS)". 

[8] 3GPP TS 25.301: "Radio Interface Protocol Architecture". 

[9] 3GPP TS 25.211: "Physical channels and mapping of transport channels onto physical channels (FDD)". 

[10] 3GPP TS 25.221: "Physical channels and mapping of transport channels onto physical channels (TDD) ". 

[II] 3GPP TS 25.304: "User Equipment (UE) procedures in idle mode and procedures for cell reselection in 

connected mode". 

[12] 3GPP TS 25.306: "UE Radio Access capabilities". 

[13] 3GPP TS 25.331: "Radio Resource Control (RRC); Protocol Specification". 

3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply. 
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Figure 3.1 : MBMS Timeline, based on [4]. 

MBMS session start is the point at which the BM-SC is ready to send data. 

MBMS notification informs the UEs about forthcoming and about ongoing MBMS data transfer. 

MBMS Cell Group is a group of multiple cells belonging to one RNS and sharing one PDCP and RLC entity to utilize 
p-t-m transmission of the MBMS Service 

MBMS session stop is the point at which the BM-SC determines that there will be no more data to send for some 
period of time. 

Data transfer is the phase when MBMS data are transferred to the UEs. 

MBMS service availability is the phase between start of service announcement and the end of the last session or stop 
of service announcement. 

MBMS lu data bearer denotes the data bearer estabUshed between SGSN and RNC to transport MBMS data 

MBMS radio bearer denotes the data bearer established between RNC and UE(s) to transport MBMS data 

MBMS RAB denotes both, the MBMS lu data bearer and the MBMS radio bearer 

MBMS Service Context contains the necessary information for the UTRAN to control the MBMS Service in UTRAN. 

MBMS Activated Services: a set of services made up of those in MBMS multicast mode that the UE has joined as well 
as those in MBMS broadcast mode that the UE is interested in receiving. 

MBMS Selected Services: a subset of the MBMS activated services in MBMS Broadcast mode for which the UE 
applies RRC procedures to inform UTRAN that the service has been selected (by upper layers). 

MBMS lu signalling connection denotes the signalling connection established between the RNC and the CN node to 
serve one MBMS Service Context. 

MBMS Service Announcement: Mechanism to allow users to be informed about the MBMS services available [4] 

Pool area: see definition in ref.[6] 

MBMS Multicast Service Activation: see description in ref.[4] 

Critical Information: MBMS Neighbouring Cell Information, MBMS Radio Bearer Information and MBMS Service 
Information sent on MCCH. 

Non-critical information: MBMS Access Information sent on MCCH. 

MBMS Service Area: The area in which a specific MBMS session is made available. Each transmission and 
retransmission of an MBMS session of an MBMS Bearer Service may be made available to a different MBMS Service 
Area. The MBMS Service Area is described by a Hst of MBMS Service Area IDs, where each MBMS Service Area ID 
represents a group of cells. The definition of an MBMS Service Area ID is independent of an MBMS session, and of an 
MBMS Bearer Service. [4] 

Ll-combining schedule: Indicates when the soft combining is applicable between the specific S-CCPCH of the cell 
and the specific S-CCPCH of the neighbouring cell. 
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MBMS service transmission schedule: Indicates when the specific MBMS service is expected to be transmitted in the 
cell in specific S-CCPCH. The information is transmitted on MSCH 

S-CCPCH: In case of TDD, the S-CCPCH refers to the CCTrCH carrying FACH 

UE Link denotes the stored information in the RNC on MBMS services joined by the UE in the state other than 
URA_PCH in the course of the UE Linking procedure. 

URA Link denotes the stored information in the RNC on MBMS services joined by a UE in URA_PCH state in the 
course of the URA Linking procedure. 

3.2 Symbols 

(void) 

3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TS 2L905 [1] and the following apply: 

CELL_DCH 

CELL_FACH 

FFS For Further Study 

FLC Frequency Layer Convergence 

LCI Layer Convergence Information 

MBMS Multimedia Broadcast Multicast Service 

MBMS service ID Multimedia Broadcast Multicast Service service Identity 

MBMS Session ID Multimedia Broadcast Multicast Service session identity 

MCCH MBMS point-to-multipoint Control Channel 

MICH MBMS notification Indicator Channel 

MSCH MBMS point-to-multipoint Scheduling Channel 

MTCH MBMS point-to-multipoint Traffic Channel 

NI Notification Indicator 

PL Preferred Layer 

p-t-p Point-to-Point 

p-t-m Point-to-Multipoint 

PF Probability Factor 



Background and introduction 



The Introduction of the Multimedia Broadcast Multicast Service in UTRA describes techniques for optimised 
transmission of MBMS bearer service in UTRA such as point-to-multipoint transmission, selective combining and 
transmission mode selection between point-to-multipoint and point-to-point bearer. 

The Stage 1 MBMS service requirements are defined in [2] and MBMS Stage 1 user services are defined in [3]. 
UTRAN (and GERAN) requirements are covered in TR 25.992 [5]. The overall architecture, functional description and 
the reference architecture of MBMS are covered in TS 23.246 [3]. 



5 IVIBIVIS UTRAN and protocol architecture 

5.1 MBMS UTRAN architecture principles 
5.1 .1 MBMS Service Context in CRNC 

Each RNC-which is controlling one or several cells within an MBMS Service area maintains an MBMS Service 
Context for each MBMS service. 
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1 Each CRNC MBMS Service Context is associated with an MBMS service ID, i.e. TMGI. 

2 The CRNC MBMS Service Context contains a Hst of PMM connected mode UEs which are present in one or 
several cells of the CRNC and which have activated the MBMS service and/or a list of URAs in which there is 
at least one URA_PCH UE which has activated the MBMS service. The hst includes at least the U-RNTI of the 
UEs in the state other than URA_PCH and/or URA-IDs. 

NOTE: The MBMS Service Context in the CRNC contains no information about RRC Idle mode UEs. 

3 The MBMS Service Context is created in the CRNC either 

if the SGSN informs the RNC that a UE has activated the MBMS Service in a cell controlled by the CRNC 
by the UE Linking procedure. In this case, the CRNC is the SRNC of the UE, 

or if the RNC is notified of an MBMS Session Start, 

- or if the RNC serves as a Drift RNC for a PMM-CONNECTED UE and receives for this UE a UE Link 
from the SRNC containing the MBMS Service Id of the concerned MBMS Service, 

or if the RNC receives a URA Link containing the MBMS Service Id of the concerned MBMS Service. 

4 Each RNC which is informed by the SGSN that a UE has activated one (or several) MBMS Service(s) by the 
UE Linking procedure maintains an MBMS Service Context for each indicated MBMS service, irrespectively 
of the MBMS Service Area. 

5 The MBMS Service Context is released by the CRNC either 

if the MBMS Service Context does not contain any UE/URA information after a UE/URA Unlinking 
procedure from a SGSN and there is no active MBMS Session for the concerned MBMS Service, 

or if the MBMS Service Context does not contain any UE Link/URA Link at the time of a Session Stop 

or if the RNC receives a CN De-Registration for MBMS Service 

6 Associated functionalities: 

6.1 Bearer type selection for MBMS transmissions based on information in the CRNC MBMS Service 
Context. The decision process requires inter-working with Radio Resource Management and with the 
UE's SRNC in the case of p-t-p bearers. 

6.2 MBMS RB control for p-t-m bearers in each cell, based on information in the CRNC MBMS Service 
Context. 

6.3 Update of the MBMS Service Context when a PMM-CONNECTED UE, which has activated an 
MBMS Service, has entered a cell. Update of the MBMS Service Context via lur is performed by UE 
Linking. 

6.4 Update of the MBMS Service Context when a PMM-CONNECTED UE, which has activated an 
MBMS Service, has left a cell. Update of the MBMS Service Context via lur is performed by UE Un- 
Linking. 

NOTE: For further details of UE linking via the lur interface see chapter 5. L6. 

5.1 .2 MBMS Session start and MBMS Session Stop 

At MBMS Session Start and MBMS Session Stop the RNC receives a respective request from the CN. The MBMS 
Session Start Request shall contain the MBMS Service Id, MBMS Bearer Service Type and MBMS Session Attributes 
(MBMS Service Area Information, QoS parameters, ...). The MBMS Session Start Request triggers the RNC to notify 
UEs, which have activated the MBMS Service of the MBMS Session Start. The MBMS Session Stop Request may 
trigger the RNC to notify UEs, which have activated the MBMS Service of the MBMS Session Stop. 

The MBMS Session Start and Session Stop procedures provide the setup and release of the MBMS RAB in the 
following way: 

The MBMS Session Start Request shall contain all information necessary to setup an MBMS RAB. When the RNC 
receives an MBMS Session Start Request, it typically executes MBMS lu data bearer set up and shall inform the 
sending CN node, of the outcome in the MBMS Session Start response message. 

Upon reception of MBMS Session Start Request, if the MBMS Service Context is not yet present in the RNC, the RNC 
shall store the MBMS Service Id. Further the RNC shall memorise the MBMS Bearer Service Type, MBMS Counting 
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Information and MBMS Session Attributes (MBMS Service Area Information, QoS parameters, ...) as part of the 
MBMS Service Context. 

The RNC may choose not to execute the MBMS lu data bearer setup, for a particular MBMS service, when: 

1 . The RNC does not control any cell contained within the MBMS Service Area, or 

2. The RNC controls at least one cell contained within the MBMS Service Area and a list of PMM-Idle Mode 
UEs is included in MBMS Session Start but no RA"s contained within the list are under the control of the 
RNC 

The RNC may not execute the MBMS lu data bearer setup for a given lu interface in case of lu-flex. In those cases the 
CN node shall be informed accordingly. 

In case of lu-flex, the RNC might receive more than one MBMS Session Start Request for an MBMS Service and shall 
not set up more than one MBMS lu bearer for a certain MBMS Service towards a pool area. 

When the RNC receives an MBMS Session Stop Request it shall release the associated MBMS RAB resources. 

The MBMS Session Start and Session Stop procedures serve to establish and release the MBMS lu signalling 
connection. 

5.1.3 MBMS lu bearer 

For each MBMS service, data is transferred via an MBMS RAB between the SGSN and the UE. For each MBMS 
service, data is transferred via one MBMS lu bearer between SGSN and the RNC in the whole MBMS Service area. 
Signalling messages specific for an MBMS Service are transferred via one dedicated MBMS lu signalling connection 
between the RNC and the SGSN. 

1 One MBMS lu bearer is established per MBMS service at MBMS Session Start. 

2 Regarding lu-flex the RNC shall not set up more than one MBMS lu bearer. 

3 Because of the dedicated channels and lur mobility, there is a need to send MBMS data to an RNC which is not 
necessarily part of the MBMS Service area. 

4 The MBMS lu bearer on lu is established per MBMS service and not per UE individually. 

5 Each PMM-CONNECTED mode UE with an activated MBMS service has its UE context bind to the MBMS lu 
bearer. 

6 There could be several MBMS RBs linked to one MBMS lu bearer (i.e. one MBMS lu bearer on lu maybe 
mapped to multiple DTCH and/or or p-t-m traffic channels over the radio -interface). 

5.1.4 MBMS lub bearer 

The existing FACH transport channel mechanism over lub is to be used in case of p-t-m MBMS transmission. 

5.1 .5 Mapping of MBMS lu bearer to p-t-p and p-t-m connections 

The service specific MBMS RAB on lu may be mapped to p-t-m bearers in order to provide MBMS data via common 
channels. 

1 The MBMS control function in the CRNC may decide to establish a p-t-m connection, if the number of counted 
MBMS users in a cell exceeds a certain operator-defined threshold or if the MBMS Counting Information 
indicates that MBMS Counting procedures are not applicable. 

2 The MBMS control function in the CRNC may decide to establish a p-t-m connection depending on the 
congestion scenario expected for a specific cell (e.g. in hotspot areas where no bearer type switching is needed), 
and/or the MBMS service characteristics (e.g. session duration time) on a per cell basis. 

3 The MBMS control function in the CRNC may, through a configurable parameter enable/disable bearer type 
switching and the associated procedures on a per cell basis. 

4 The MBMS control function in the CRNC establishes an MBMS RB by sending service specific signalling 
messages (e.g. MBMS RB Setup message) to all the UEs in the cell listening MBMS point-to-multipoint 
control channel (MCCH). UEs with activated service(s) may then execute the RB set-up. 
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5 MBMS data is transferred on an MBMS point-to-multipoint traffic channel (MTCH) to all the UEs which have 
executed the RB setup. 

6 The MBMS control function in the CRNC releases the MBMS RB (e.g. MBMS RB Release) when the data 

transfer has been finished or it has been interrupted by the CRNC. 

7 p-t-p transmission of MBMS data should use the DTCH as defined for other dedicated services. 

8 p-t-m transmission of MBMS data applies to all RRC states and modes. 

5.1.6 UE Linking/De-linking 

UE Linking denotes the process where a UE, which has joined one or several MBMS services, is linked to one or 
several MBMS service context in the RNC. 

MBMS UE linking procedure in the SRNC is performed in following cases. 

1 . When the UE, which has joined an MBMS service, is moved to PMM-CONNECTED and sets up a PS RAB 
This may happen at any point in time during the whole MBMS service availability (i.e. before, during and 
between MBMS sessions). 

2. When the UE joins an MBMS service and is in PMM-CONNECTED due to an existing PS RAB. This may 
happen at any point in time during the whole MBMS service availability (i.e. before, during and between MBMS 

sessions). 

3. When the UE is moved to PMM-CONNECTED only for MBMS purpose, e.g. to respond to counting/recounting 
indication or respond to p-t-p bearer indication from RNC. This may happen at any point in time during MBMS 
sessions. 

4. When the UE is moved to PMM-CONNECTED and the UE provides MBMS Selected Services Information to 
the RNC. 

Keeping UEs in PMM-CONNECTED only for MBMS between sessions is implementation specific. The UE linking in 
the SRNC for services delivered over MBMS Multicast mode is performed via UE dedicated lu procedures. An entry 
for the UE is added to the related MBMS service context(s) in the SRNC. If an MBMS service context does not exist 
yet it needs to be created. 

In cases where a UE is present in a cell under the control of a drift RNC, the UE Linking is performed via lur in the 
following way. 

1 . When the UE, which has activated one or several MBMS services, is in CELL_DCH state and starts to 
consume radio resources from one or several cells controlled by the DRNC, MBMS UE Linking in the DRNC 
is performed via UE dedicated lur procedures. After that the DRNC shall update the MBMS Service context 
on the request of every radio link setup/release from the SRNC. 

2. When the UE, which has activated one or several MBMS services, is in CELL_FACH state and starts to 
consume radio resources from one cell controlled by the DRNC, MBMS UE Linking in the DRNC is 
performed via UE dedicated lur procedures. After that the DRNC shall update the MBMS Service context in 
the DRNC at every intra-DRNC cell change without the need to receive UE Link from the SRNC. 

3. If the UE is in CELL_DCH and CELL_FACH state and there is no dedicated RNL signalling activity ongoing 
for this UE and UE Linking is performed in the SRNC for an MBMS Service, MBMS UE Linking in the 
DRNC is performed via the MBMS Attach procedure. 

4 If the UE is in CELL_PCH and moves to a cell within the DRNC area for the first time, the MBMS UE 
Linking in the DRNC is performed. The cell the UE moved to is indicated to the DRNC. After that at every 
intra-DRNC cell change the DRNC shall update the MBMS Service context in the DRNC without the need to 
receive UE Link from the SRNC. 

5. If the UE is in CELL_PCH and there is no mobility related signalling activity ongoing for this UE and UE 
Linking is performed in the SRNC for an MBMS Service, MBMS UE Linking in the DRNC is performed via 
the MBMS Attach procedure. 

6 If the UE is in RRC connected mode and UE Linking is performed in the SRNC for an MBMS Service and a 
session of this MBMS Service is ongoing UE Linking in the DRNC needs to be performed immediately. 
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At MBMS UE linking in the DRNC the MBMS service context in the DRNC needs to be updated. If an MBMS 
service context does not exist yet then it shall be created and if needed, DRNC can acquire the APN and IP 
Multicast Address from the SRNC for the specific service via Information Exchange procedure. 

UE De-linking denotes the process where a UE, which has joined MBMS service(s), is removed from one or 
several MBMS service contexts in the RNC. 

MBMS UE De-linking procedure in the SRNC is performed in following cases. 

1 . When the UE has left the MBMS service and is in PMM-CONNECTED due to an existing PS RAB. This may 
happen at any point in time during the whole MBMS service availability (i.e. before, during and between 
MBMS sessions). 

2. When the UE sends new MBMS Selected Services Information to the RNC omitting an MBMS service which 
is identified on the MCCH. 

3. When CN decides to de-link a certain PMM-CONNECTED mode UE due to e.g. error cases. 

MBMS UE De-linking in the SRNC for services in MBMS Multicast mode is performed via UE dedicated lu 
procedure. The entry for the UE is removed from the concerned MBMS service context(s) in the SRNC. 

MBMS UE De-linking procedure in the DRNC is performed via lur in the following way: 

1 . If the UE is in CELL_DCH or CELL_FACH state and stops consuming the radio resources from one or 
several cells controlled by the DRNC, MBMS UE is De-linked from the MBMS Service Context in the DRNC 
via UE dedicated lur procedure. 

2. If the UE is in CELL_DCH or CELL_FACH state and there is no dedicated RNL signalling activity ongoing 
for this UE and UE De-linking is performed in the SRNC for an MBMS Service, MBMS UE De-linking in the 
DRNC is performed via the MBMS Detach procedure. 

3 If the UE is in CELL_PCH and leaves for a cell out of the DRNC area the UE is deUnked from the MBMS 
Service context in the DRNC via the MBMS Detach procedure. The cell the UE moved out of is indicated to 
the DRNC. 

4. If the UE is in RRC connected mode and UE De-linking is performed in the SRNC for an MBMS Service 
and a session of this MBMS Service is ongoing UE De-linking in the DRNC needs to be performed 
immediately. 



5.1.7 RNC Registration 



RNC Registration for a certain MBMS Service denotes the process where the CN becomes aware of an RNC hosting 
UEs, which have activated that MBMS Service. 

Due to UE mobility, a RNC with no MBMS Service Context, can be informed that a PMM-CONNECTED UE, which 
has entered the cell, has activated an MBMS Service by means of the MBMS UE Linking procedure via the lur 
interface. Then the RNC informs the CN that it would like to receive MBMS Session Start Request messages when 
applicable for the concerned MBMS Service by sending MBMS Registration Request message. 

It results in the set-up of a corresponding MBMS distribution tree, but it does not result in the establishment of lu user 
plane, which will be established by the MBMS Session Start procedure. 

1 . Implicit Registration 

RNC Registration for Serving RNCs is performed implicitly, i.e. due to UE linking and MBMS Multicast 
Service Activation. No explicit registration procedure needs to be performed. 

2. ExpUcit Registration 

RNC Registration for Drift RNCs is performed explicitly if an RNC becomes a Drift RNC for a UE, which 
has activated an MBMS service and has no MBMS Service Context for that MBMS Service. 

RNC Registration for Drift RNCs is performed explicitly if an RNC is no longer the SRNC of any 
connected UE which has activated an MBMS service, but hosts at least a UE which consumes radio 
resources of the RNC via lur. This shall happen only before sessions or between sessions. 

The DRNC will perform a registration towards its default CN node only. 
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5.1.8 RNC De-Registration 



RNC De-Registration for a certain MBMS Service denotes the process where the CN becomes aware that an RNC 
registered at a CN node does not host any more PMM-CONNECTED UEs which have activated that MBMS Service. 

• Implicit RNC De-Registration 

RNC De-Registration for Serving RNCs is performed implicitly, i.e due to UE Unlinking and MBMS 
Multicast Service Deactivation. No explicit de-registration procedure needs to be performed. 

• Explicit RNC De-Registration 

RNC De-Registration for Drift RNCs is performed explicitly if a RNC is not acting as a Serving RNC and 
has ceased to act as a Drift RNC for UEs which have activated an MBMS service, it will perform a de- 
registration towards the CN node it was registered to. 

The timing of RNC De-Registration is implementation specific. 

NOTE: When the Drift RNC performes the explicit De-registration, the Implicit registration may still remain and 
in that case lu data bearer should not be removed. 

5.1.9 CN De-Registration 

CN De-Registration denotes the process where the CN informs the RNC that a certain MBMS service is no longer 
available. CN De-Registration should result in releasing of all associated MBMS Service Contexts and resources. 

The CN De-Registration procedure serves to release the MBMS lu signalling connection. 



5.1.10 URA Linl<ing/De-linl<ing 



URA Linking denotes the process where a URA, which contains one or more cells in which at least one URA_PCH UE 
has joined the MBMS service or has passed MBMS Selected Service Information about the MBMS service, is linked to 
an MBMS service context in the RNC. An entry for the URA is added to the MBMS service context in the RNC. 

If the UE in URA_PCH state, which has activated one or several MBMS Services, is present within a URA containing 
one or more cells that are controlled by one or more drift RNCs, the URA Linking is performed in the following way. 

1 . If the UE is in URA_PCH, having activated one or more MBMS services, is the first UE for the particular 
MBMS service to move to a URA which contains one or more cells that are controlled by one or more 
DRNCs, the URA is linked to the MBMS Service context in each applicable DRNC. The URA the UE 
moved to will be indicated. 

2. As long as the SRNC serves UEs in URA_PCH in URAs containing cells controlled by one or more DRNCs, 
the SRNC shall keep the other RNCs informed about every URA in which UEs having activated certain 
MBMS services have to be notified. This is done when the first UE enters the URA, by indicating to the 
other RNCs a list of URAs and the corresponding MBMS Services via MBMS Attach procedure. 

NOTE: Bullet points 1 and 2 above may be merged in a future version of this document. 

At MBMS URA linking in the RNC the MBMS service context in the RNC needs to be updated. If an MBMS service 
context does not exist yet then it shall be created and acquire the APN and IP Multicast Address from the SRNC for the 
specific service via Information Exchange procedure. 

URA De-linking denotes the process where a URA is removed from one or several MBMS service contexts in the RNC. 

1 . If the UE is in URA_PCH and, for the particular MBMS service, is the last UE to leave a URA which 

contains one or more cells controlled by one or more DRNCs the URA is de-linked from the MBMS Service 
context in each applicable DRNC via the MBMS Detach procedure. 
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5.2 MBMS Uu Principles 

5.2.1 IVIBIVIS Service States in UE 

The MBMS bearer service has following service states in the UE: 

1. Not active, UE has not joined any MBMS multicast service or not activated the broadcast mode of the MBMS 

2. Not active, UE has joined at least one MBMS multicast service and/or activated the broadcast mode of the 
MBMS, but MBMS SYSTEM INFORMATION is not broadcasted on BCCH. 

3. Active, UE has joined at least one MBMS multicast service and/or activated the broadcast mode of the MBMS, 
but any of the services that UE has joined (interested in broadcast mode) is not being transmitted. UE monitors 
MICH to find modifications in the MCCH as defined in 5.1.6 

4. Active; at least one MBMS service appearing in the list of MBMS Activated Services, is received on p-t-m 

UE is receiving MBMS transmission on MTCH 

UE is using DRX based on scheduling information informing that coming MTCH transmission is not 
in the interest of the UE. 

5. Active; at least one MBMS service received on p-t-p 

6. Active; at least one MBMS service is received on p-t-p and at least one MBMS service is received on p-t-m. 
(only valid if UE has capability to support this combination) 

When MBMS transmission is started in cell the UE moves from state 3 to either state 4 or state 5 (6), depending on 
p-t-p transmission mode and after MBMS transmission ends in the cell, the UE moves from state 4 or state 5 (6) to state 

3. 

5.2.2 One PDCP and RLC entity sinared among multiple cells within one 
RNS 

For each MBMS service, a group of multiple cells belonging to one RNS shares one PDCP entity and RLC entity over 
p-t-m transmission. The group of multiple cells is called 'MBMS Cell Group'. 

1 . There are one or more MBMS Cell Groups per RNS. The MBMS Cell Groups are managed by the CRNC. 

2. There are one or more cells pertaining to the same RNS for one MBMS Cell Group. 

3. The MBMS Cell Group identity is used to uniquely identify a group of multiple cells, which for each MBMS 
service share the same PDCP entity and RLC entity within an RNS. 



5.2.3 MCCH Information Scheduling 



The MCCH information will be transmitted based on a fixed schedule. This schedule will identify the TTI containing 
the beginning of the MCCH information. The transmission of this information may take a variable number of TTIs and 
the UTRAN should transmit MCCH information in consecutive TTIs. The UE will keep receiving the S-CCPCH until: 

It receives all of the MCCH information, or 

It receives a TTI that does not include any MCCH data, or 

The information contents indicate that further reception is not required (e.g. no modification to the desired 
service information). 

Based on this behaviour, the UTRAN may repeat the MCCH information following a scheduled transmission in order to 
improve reliability. The MCCH schedule will be common for all services. 

The entire MCCH information will be transmitted periodically based on a "repetition period". The "modification 
period" will be defined as an integer multiple of the repetition period. The MBMS ACCESS INFORMATION may be 
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transmitted periodically based on an "access info period". This period will be an integer divider of the "repetition 
period". 

MCCH information is split into critical and non-critical information. The critical information is made up of the MBMS 
NEIGHBOURING CELL INFORMATION, MBMS SERVICE INFORMATION and MBMS RADIO BEARER 
INFORMATION. The non-critical information corresponds to the MBMS ACCESS INFORMATION. Changes to 
critical information will only be applied at the first MCCH transmission of a modification period and in the beginning 
of each modification period UTRAN transmits the MBMS CHANGE INFORMATION including MBMS services ids 
whose MCCH information is modified at that modification period. MBMS CHANGE INFORMATION is repeated at 
least once in each repetition period of that modification period. Changes to non-critical information could take place at 
any time. 

The Figure 1 below illustrates the schedule with which the MBMS SERVICE INFORMATION and RADIO BEARER 
INFORMATION would be transmitted. Different colours indicate potentially different MCCH content. 
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Figure 5.2.3: MCCH Information Schedule 

5.2.4 MBMS Notification 

The MBMS notification mechanism is used to inform UEs of an upcoming change in critical MCCH information. 
Notifications are based on service groups. The mapping between service IDs and service groups is specified in [11]. 

The MBMS notification indicators will be sent on an MBMS specific PICH, called the MICH. A single MICH frame 
will be able to carry indications for every service-group. 

Critical MCCH information can only be changed at the beginning of a modification period as described in Section 5.2.3. 
The MBMS notification indicator corresponding to the service group of every affected service shall be set continuously 
during the entire modification period preceding the first change in MCCH information related to a given service. 
Subsequent changes in the MCCH information in the next modification period related to the same service can be 
signalled on the MCCH. 

UEs which are not receiving any MBMS service on MTCH or p-t-p channel are free to read the MBMS notification at 
any time; however the modification interval shall be long enough so that UEs are able to reUably detect it even if they 
only receive the MICH during their regular Release '99 paging occasions. 

Upon detecting the MBMS notification indication for a service group, UEs interested in a service corresponding to this 
group shall start reading the MCCH at the beginning of the next modification period. The UE shall read at least MBMS 
CHANGE INFORMATION. 

The Figure 2 below illustrates the timing relation between the setting of the MICH and the first MCCH critical 
information change. The green colour for the MICH indicates when the NI is set for the service. For the MCCH, 
different colours indicate MCCH content related to the notification of different services. 

UEs, which are receiving MBMS service(s) on MTCH in idle mode or URA_PCH, CELL_PCH, or CELL_FACH state 
shall read the MCCH at the beginning of the each modification period to receive the MBMS CHANGE 
INFORMATION, which will indicate MBMS service Ids and optionally MBMS Session ID whose MCCH information 
is modified at that modification period. If MBMS service Id and optionally MBMS Session ID, which UE has activated, 
is indicated in MBMS CHANGE INFORMATION the UE shall read the rest of the MCCH information. 
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Figure 5.2.4: Illustration of MICH timing relative to Modification period 



5.2.5 MBMS Counting 



MBMS Counting is used to determine the optimum transmission mechanism for a given service. 

1. The need for counting is indicated in the notification, and achieved by requesting UEs, belonging to the same 
MBMS service group, to respond to counting by sending MBMS COUNTING RESPONSE signalling flow to 
CRNC. 

a. For UEs in idle mode the counting response refers to the RRC connection establishment procedure. 

b. For UEs in URA_PCH, or CELL_PCH state the counting response refers to cell update procedure 
c. For UEs in CELL_FACH state the counting response refers to signalling on CCCH or DCCH. 

2. The exact number of UEs that need to respond to counting is an RRM issue. 

3. Since it is desirable in a specific cell, to avoid bringing a large number of UEs for counting purposes to RRC 
connected mode at the same time (RACH load, etc), RRM may control the load due to the RRC connection 
establishment requests, by setting an access "probability factor". For UEs in PMM connected mode the 
UTRAN may set different "probability factor" than for UEs in idle mode. 

4. Following counting, the number of subscribers that need to be maintained in RRC connected mode or for 
which the RNC releases their connection, is also an RRM issue. 

5. For a given MBMS service, the counting indication in the notification may be switched on and off, on per-cell 

basis. 

6. The RNC may use notification to indicate counting during an ongoing MBMS session (term used is re- 
counting). 

7. The RNC receives via lu from CN information (MBMS service ID) about UEs who are in RRC Connected 
mode, and have joined the MBMS service. This information may be used for counting purposes. 

The MBMS counting function includes a mechanism by which the UTRAN can prompt users interested in a given 
service to become RRC connected. This procedure is only applicable for UEs in idle mode and relies on the MBMS 
ACCESS INFORMATION transmitted on the MCCH. The probability factor indicates the probabiUty with which UEs 
need to attempt an RRC connection procedure. 

In order to trigger counting for a given service, the UTRAN may use the regular MBMS notification mechanism 
outlined in section 5.2.4 to force UEs interested in the service to read the MCCH information. 

Once a UE detects that the counting procedure is on-going for the specific service it wants to receive, it will attempt to 
respond to the counting based on the probability factor included in the MCCH. If the response to counting is for a 
service identified in the list of MBMS Selected Services, the UE should provide the MBMS Service ID in the response. 
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Also, the UE will keep receiving the MBMS ACCESS INFORMATION at every access info period until the UE 
successfully responds to the counting or counting is no longer required. Whenever it receives new MBMS ACCESS 
INFORMATION the UE will update its probability factor with the new value. 

The Figure 3 below illustrates this mechanism. The green colour for the MICH indicates when the NI is set for the 
service. The green colour for the MBMS ACCESS INFORMATION indicates that the counting procedure is on-going 
and that UEs need to establish an RRC connection based on the included probability factor (PF). For the critical MCCH 
info, different colours indicate potentially different content. 
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Figure 5.2.5: Illustration of Access Info period during MBMS counting 

For every UE brought to RRC connected state for the purpose of counting, UTRAN will initiate the PMM Connection 
establishment procedure and will obtain from CN the set of MBMS services these users have joined. 

Counting for on-going services (re-counting) will rely on the same scheduling of the MCCH information. 

5.2.6 MBMS Radio Bearer Release in tine UE 

The UE releases the MBMS RB by using one of the following mechanisms: 

- Exphcit MBMS RB Release 

- Imphcit MBMS RB Release 

The Explicit MBMS RB Release mechanism allows UTRAN to explicitly indicate to MBMS UEs that an MBMS Radio 
Bearer should be released. For p-t-m transmissions the Explicit MBMS RB Release indication is contained within the 
MBMS SERVICE INFORMATION signalling flow. For p-t-p transmission the release of MBMS radio bearers is 
completed in the same way as for a non-MBMS radio bearer. If the Explicit MBMS RB Release indication is received, 
the UE releases the MBMS RB. 

The Implicit MBMS RB Release mechanism applies only to p-t-m transmission and enables a UE to release the MBMS 
Radio Bearer without receiving the Explicit MBMS RB Release. The UE identifies Implicit MBMS RB release if it 
detects that the RB is not present in the MBMS SERVICE INFORMATION signalling flow. 
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5.2.7 MBMS Session Repetition 



In the case that the BM-SC repeats MBMS sessions (send multiple time identical content), the MBMS service Id and 
MBMS session Id is used to identify specific MBMS service and session. The validity of the session Id is handled on 
the MBMS application layer between the BM-SC and the UE. If UTRAN receives the MBMS session ID in session 
start, the UTRAN should: 

■ include MBMS session Id in critical and non critical information send on MCCH 
Note: The non-critical information may contain index referring to critical information, 
avoiding repetition of MBMS service and session Id in non-critical information. 

If the UE has already received correctly the data of the MBMS session, which is being indicated on MCCH, the UE 
may: 

ignore PLC by not applying the Layer Convergence Information 

ignore counting procedure in Idle, URA_PCH, CELL_PCH, and CELL_FACH state 

ignore p-t-m MBMS RB setup signalled on MCCH 

ignore p-t-p MBMS RB indication signalled on MCCH 

reject the p-t-p RB setup for MBMS service, signalled on DCCH 

In the case that UTRAN receives reject from the UE to the p-t-p RB setup for MBMS service on DCCH, the UTRAN 
should not try to re-establish p-t-p RB setup for that MBMS service and session. 

In the case that the UE has accepted the p-t-p RB for repeated MBMS session the UE shall receive the complete 
session. 

5.2.8 MBMS Service Prioritisation 

The CN may assign the Allocation and Retention Priority for the MBMS bearer service. The Allocation and Retention 
Priority allows for prioritisation between MBMS bearer services and between MBMS bearer services and non MBMS 
bearer services in the UTRAN. 

The UE may assign internally different priorities for different MBMS services to prioritise MBMS and non MBMS 
service reception. In case that UE has no capability to receive simultaneously, the dedicated non MBMS service and the 
MBMS service and the MBMS service has priority over the non MBMS service the UE may: 

■ initialise signalling with CN on NAS layer to stop reception of dedicated non MBMS service 

If the UE has no capacity on receiving all MBMS services, which it has activated and which are transmitted 
simultaneously on p-t-m RBs, the UE may 

■ stop autonomously ongoing reception of lower priority MBMS service 

■ act on MCCH message assigned to the highest priority MBMS service 

■ start autonomously the reception p-t-m RB of the highest priority MBMS service 

If the reception p-t-p RB of the lower priority MBMS service is blocking the reception of p-t-m RB of the higher 
priority MBMS service the UE may: 

If p-t-p RB is being established 

■ reject the setup of p-t-p MBMS RB 

If the UTRAN receives reject message UTRAN should not try to re-establish p-t-p RB setup for that MBMS service 
and session. 

If p-t-p RB is already existing 

■ request the release of p-t-p MBMS RB from the UTRAN or only indicate frequency of 
higher priority MBMS service 
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If the UTRAN receives release request message UTRAN may release the p-t-p MBMS RB. 



5.3 



Protocol structure 



5.3.1 MBMS User Plane Protocol Stack Architecture 
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Figure 5.3.1 : Protocol Stack for MTCH 

Figure 5.3.1 illustrates the protocol termination for MTCH in MBMS, which is used in p-t-m transmission. 

If configured by CRNC the PDCP sub-layer performs header compression/decompression for the MBMS traffic. 

The PDCP sub-layer may operate with the RFC 3095 header compression protocol. In that case, header compression 
should be performed under RFC 3095 U-mode. 

In the UTRAN, for p-t-m transmission, there is one PDCP entity for each MBMS service for each MBMS Cell Group 
that provides the service (an MBMS Cell Group may contain one or more than one cell). 

In the UTRAN, for p-t-m transmission, there is one RLC entity for each MBMS service in each cell or cell group in 
case of utilization of selective combining or maximum ratio combining in TDD, and one MAC entity for each cell. 

In the UE side, there is one PDCP and RLC entity for each MBMS service in each UE. In each UE there is one MAC 
entity per received cell when UE is performing the selective combining between these cells. 

In case of p-t-p transmission, DTCH is used for MBMS transmission and the protocol termination for DTCH mapped 
on DCH and RACH/FACH are presented in [8]. 

5.3.2 MBMS Control Plane Protocol Stack Architecture 
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Figure 5.3.2: Protocol Stack for MCCH and MSCH 



Figure 5.3.2 illustrates the protocol termination for MCCH and MSCH in MBMS, which are MBMS p-t-m control 
channels. 

MBMS functionahties are included in MAC and RRC. 
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In case of p-t-p transmission, DCCH is used for MBMS and the protocol termination for DCCH mapped on DCH and 
FACH are presented in [8]. 



5.4 



MAC architecture 



5.4.1 UTRAN MAC Architecture to support IVIBIVIS 
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Figure 5.4.1 : UTRAN MAC architecture 

To support MBMS user and control plane transmission, a multicast functionality is added in the MAC c/sh, entitled 
"MAC m", to take care of scheduling of MBMS related transport channels as presented in Figure 5.4.1. In addition, 
three logical channels are considered for p-t-m transmission of MBMS: MCCH, MSCH and MTCH. These logical 
channels are mapped on FACH. In case of p-t-p transmission DTCH and DCCH are used. 

5.4.2 IVIAC-c/sh/m architecture: UTRAN side 

Figure 4 illustrates the MAC-m additions to the MAC -c/sh architecture in the UTRAN side, needed to transmit MBMS 
data over a common transport channel (FACH). 

MAC-c/sh/m is located in the controlling RNC. The following functionalities are covered: 

Scheduling / Buffering / Priority Handling: This function manages common transport resources between 
MBMS and non-MBMS data flow(s) according to their priority and delay requirements set by higher 
layers. 

TCTF MUX: This function handles insertion of the TCTF field in the MAC header and also the respective 
mapping between logical channels (i.e. MTCH and MCCH) and transport channels. The TCTF field 
indicates which type of logical channel (i.e. MTCH and MCCH) is used. 

Addition of MBMS-ID: For p-t-m type of logical channels, the MBMS-ID field in the MAC header is 
used to distinguish between MBMS services. 

TFC selection: Transport format combination selection is done for a common transport channel (FACH) 
mapped to MTCH, MSCH and MCCH. In the case of MBMS soft combining (excluding TrCH combining 
in TDD), the combinable S-CCPCHs shall have the same TFC during the TTIs in which LI combining is 
used. 

There is one MAC-c/sh/m entity in the UTRAN for each cell. 
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Figure 5.4.2: UTRAN side lUIAC-m architecture additions to lUIAC-c/sh 



5.4.3 MAC-c/sh/m architecture: UE side 

Figure 5 illustrates the MAC-m additions to the MAC-c/sh architecture in the UE side, needed to receive MBMS data 
over a transport channel (FACH). 

The following functionalities are covered: 

- TCTF DEMUX: This function handles detection and deletion of the TCTF field in the MAC header, and 
also the respective mapping between logical channels (i.e. MTCH and MCCH) and transport channels. 
The TCTF field indicates which type of logical channel (i.e. MTCH and MCCH) is used. 

Reading of MBMS-ID: The MBMS-ID identifies data to a specific MBMS service. 

There is one MAC-m entity in the UE or in case of selective combining one MAC-m entity for each selectively 
combined cell in the UE. 



MAC-Control 




fach' fach' 



Figure 5.4.3: UE side IVIAC-m additions to IVIAC-c/sh 
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6 MBMS Channel Structure 

There exists two transmission modes to provide the MBMS service: 
Point-to-point transmission (p-t-p) 
Point-to-muhipoint transmission (p-t-m) 

6.1 Point-to-Point Transmission 

Point-to-point transmission is used to transfer MBMS specific control/user plane information as well as dedicated 
control/user plane information between the network and one UE in RRC Connected Mode. It is used only for the 
multicast mode of MBMS and for services identified in the list of MBMS Selected Services. 

For a UE in CELL_FACH and Cell_DCH, DCCH or DTCH is used, allowing all existing mappings to transport 
channels. 

A detailed description of channels used for point-to-point transmission is given in [8]. 

6.2 Point-to-multipoint Transmission 

Point-to-multipoint transmission is used to transfer MBMS specific control/user plane information between the network 
and several UEs in RRC Connected or Idle Mode. It is used for broadcast or multicast mode of MBMS. 

6.2.1 Logical Channels 

6.2.1 .1 MBMS point-to-multipoint Control Channel (MCCH) 

This logical channel is used for a p-t-m downlink transmission of control plane information between network and UEs 
in RRC Connected or Idle Mode. The control plane information on MCCH is MBMS specific and is sent to UEs in a 
cell with an activated (joined) MBMS service. MCCH can be sent in S-CCPCH carrying the DCCH of the UEs in 
CELL_FACH state, or in standalone S-CCPCH, or in same S-CCPCH with MTCH. 

The MCCH is always mapped to one specific EACH in the S-CCPCH as indicated on the BCCH. If MCCH is the only 
logical channel mapped in to the EACH, the absence of the TCTF field is explicitly signalled otherwise the TCTF field 
is used in MAC header to identify MCCH logical channel type. In case of soft combining, the MCCH is mapped to a 
different S-CCPCH (CCTrCH in TDD) than MTCH. 

Reception of paging has priority over reception of MCCH for Idle mode and URA/CELL_PCH UEs. 

6.2.1 .2 MBMS point-to-multipoint Traffic Channel (MTCH) 

This logical channel is used for a p-t-m downlink transmission of user plane information between network and UEs in 
RRC Connected or Idle Mode. The user plane information on MTCH is MBMS Service specific and is sent to UEs in a 
cell with an activated MBMS service. 

The MTCH is always mapped to one specific EACH in the S-CCPCH as indicated on the MCCH. The TCTE field is 
always used in MAC header to identify MTCH logical channel type. 

6.2.1.3 MBMS point-to-multipoint Scheduling Channel (MSCH) 

This logical channel is used for a p-t-m downlink transmission of MBMS service transmission schedule between 
network and UEs in RRC Connected or Idle Mode. The control plane information on MSCH is MBMS service and S- 
CCPCH specific and is sent to UEs in a cell receiving MTCH. One MSCH is sent in each S-CCPCH carrying the 
MTCH. 

The MSCH is always mapped to one specific EACH in the S-CCPCH as indicated on the MCCH. Due to different error 
requirements the MSCH is mapped to a different EACH than MTCH. If MSCH is the only logical channel mapped in to 
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the FACH, the absence of the TCTF field is explicitly signalled otherwise the TCTF field is used in MAC header to 
identify MSCH logical channel type. 

6.2.2 Transport Channel 

FACH is used as a transport channel for MTCH, MSCH and MCCH. 

6.2.3 Physical Channel 

SCCPCH is used as a physical channel for FACH carrying MTCH or MCCH or MSCH. 

6.2.4 Mapping between channels 

Only in downlink, the following connections between logical channels and transport channels exist: 

- MCCH can be mapped to FACH 

- MTCH can be mapped to FACH 

- MSCH can be mapped to FACH 

The mappings as seen from the UE and UTRAN sides are shown in Figure 6.2.4-1 and Figure 6.2.4-2 respectively. 



MSCH- MCCH- MTCH- 
SAP SAP SAP 




MAC SAPs 



Transport 
FACH Channel 

Figure 6.2.4-1 : Logical channels mapped onto transport channel, seen from the UE side 

MSCH- MCCH- MTCH- 
SAP SAP SAP 

MAC SAPs 




Transport 
FACH Channel 

Figure 6.2.4-2: Logical channels mapped onto transport channel, seen from the UTRAN side 
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6.2.5 Data Flows through Layer 2 

6.2.5.1 Data flow for MCCH mapped to FACH 

For MCCH, the RLC mode to be employed is UM-RLC, with required enhancements to support out of sequence SDU 
deHvery. A MAC header is used for logical channel type identification. 

6.2.5.2 Data flow for MTCH mapped to FACH 

For MTCH, the RLC mode to be employed is UM-RLC, with required enhancements to support selective combining. 
Quick repeat may be used in RLC-UM. A MAC header is used for logical channel type identification and MBMS 
service identification. 

6.2.5.3 Data flow for MSCH mapped to FACH 

For MSCH, the RLC mode to be employed is UM-RLC. A MAC header is used for logical channel type identification. 

6.3. MBMS Notification Indicator Channel 

MBMS notification utilizes a new MBMS specific PICH called the MBMS Notification Indicator Channel (MICH) in 
each cell. Its coding is defined in [9] (FDD) and [10] (TDD). 



7 MBMS Reception and UE Capability 

7.1 Selective and Soft Combining for MBMS P-T-M 
transmission 

The selective combining for MBMS p-t-m transmission is supported by RLC PDU numbering. Therefore, the selective 
combining in the UE is possible from cells providing similar MBMS RB bit rate, provided that the de-synchronization 
between MBMS p-t-m transmission streams does not exceed the RLC re-ordering capability of the UE. Thus, there exist 
one RLC entity in the UE side. 

To support selective combining it is decided to: 

Introduce re-ordering as a configurable feature of RLC-UM, within the RLC specification. 

Use the same mechanism as what is specified for MAC-hs (single Tl timer). 

For selective combining there exist one RLC entity per MBMS service utilizing p-t-m transmission in the cell group of 
the CRNC. All cells in the cell group are under the same CRNC, i.e. lur support is not considered. 

For soft combining to be possible, the relative delay between the radio links to be combined, when they are received by 
the UE, must be no more than (1 TTI)h-(1 slot). 

The UE capability requirements to support selective and soft combining are defined in chapter 7.2. In case de- 
synchronization occurs between MBMS transmissions in neighbouring cells belonging to an MBMS cell group the 
CRNC may perform re-synchronization actions enabling UEs to perform the selective combining between these cells. 

For TDD, selection combining and soft combining can be used when Node-Bs are synchronised. For FDD soft 
combining can be used when Node-Bs are synchronized inside UE"s soft combining reception window, and the data 
fields of the soft combined S-CCPCHs are identical during soft combining moments. 

When selective or soft combining is available between cells the UTRAN should send MBMS NEIGHBOURING CELL 
INFORMATION containing the MTCH configuration of the neighbouring cells, available for selective or soft 
combining. When partial soft combining is applied the MBMS NEIGHBOURING CELL INFORMATION contains the 
LI -combining schedule, which indicates the time moments when the UE may soft combine the S-CCPCH transmitted in 
neighbouring cells with the S-CCPCH transmitted in the serving cell. With MBMS NEIGHBOURING CELL 
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INFORMATION the UE is able to receive MTCH transmission from neighbouring cell without reception of the MCCH 
of that cell. 

The UE determines the neighbouring cell suitable for selective or soft combining based on threshold (e.g. measured 
CPICH Ec/No) and the presence of MBMS NEIGHBOURING CELL INFORMATION of that neighbour cell. 

The possibility of performing selective or soft combining should be signalled to the UE. 

7.1 .bis Simulcast Combining (TDD only) 

In contrast to FDD, downlink macro diversity has not been a characteristic of TDD during release '99/4/5. As such 
TDD receivers are not typically designed to facilitate the simultaneous reception of multiple radio links and the 
incorporation of such a requirement for MBMS in TDD would have non-trivial impacts on the receiver design. 

Much of the receiver complexity increase associated with the combining of multiple radio links in the UE can however 
be avoided in TDD by combining macro-diversity with timeslot re-use. This also allows for the throughput gains from 
timeslot re-use to be combined with further gains from macro diversity. 

In such a scheme, the transmissions of the same information from the multiple participating cells are arranged such that 
they arrive at the UE on substantially different timeslots, thereby removing the requirement at the UE to detect multiple 
cells in the same timeslot. 

As such, cells are partitioned into transmission "groups" or "sets". Each transmission set is allocated a timeslot (or set 
of timeslots) for MBMS transmission. The assigned slots are typically exclusively used by that MBMS set; sets do not 
transmit when another set is active. The UE attempts to receive information from each set and to combine them either 
at the physical layer or RLC layer in order to enhance reception reliability. 

Figure 7.1. bis shows such a scheme applied to a tri-sectored deployment model. 3 timeslots (ti, t2 and t^) are allocated to 
each sector for the purposes of MBMS transmission. Each sector is assigned to a particular "MBMS transmission set", 
set 1, 2 or 3. 

An MBMS data unit or transport block is encoded over several radio frames (eg: 80ms TTI). The physical channel bits 
that result are effectively transmitted three times; once by MBMS set 1 in timeslot ti, once by MBMS set 2 in timeslot 
t2, and once by MBMS set 3 in timeslot t^. 
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Figure 7.1. bis: Example of non-time-coincident macro diversity transmission 

A given UE may be configured to listen to the separate transmissions of the MBMS physical channels (one from each 
set) which, over the course of the TTI, correspond to the MBMS transport block(s). The signals from each MBMS set 
are largely non-time-coincident and do not require the use of an extensively modified receiver architecture -a receiver 
architecture resembling that of a normal "single -radio-link" TDD receiver may be used. 

The received transport blocks may be provided to the RLC layer for selective combining, or soft information may be 
buffered and combined across MBMS sets during the course of the TTI via physical layer soft combining . 

The UTRAN shall signal to the UE on the MCCH which services may be soft combined (and in which cells). The cell 
group for soft combining may be different than the cell group for selective combining. The UE may assume that 
transmissions of a given service that may soft combined take place in the same frame. 



7.2 



UE Capability 



The UE MBMS capability is not sent to UTRAN and is subject to UE implementation, including the relation between 
MBMS capability and actual RRC state which is also a UE implementation. A consequence is that a UE may be 
counted although its actual capability does not allow to receive MBMS transmissions e.g. because of its current RRC 
state. 

The standard will describe a minimum UE capability requirement in order to allow operators to configure MBMS 
channels that can be common to all UEs supporting the given service. 
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There are some UE capability requirements that are common to all eventual service categories: 

The minimum UE capability for MBMS capable UE, is one primary CCPCH plus all the configurations below. The UE 
is not required to support these configurations simultaneously. 

1 . One PICH and one MICH 

2. One S -CCPCH and one MICH 

3. One S-CCPCH (dedicated EACH and possibly the EACH, which may carry MCCH) and two S-CCPCH with 
80ms TTI for MTCH reception 

4. One S-CCPCH (dedicated EACH and possibly the EACH, which may carry MCCH) and three S-CCPCH with 
40ms TTI for MTCH reception 

5. One PICH and two S-CCPCH with 80ms TTI for MTCH reception 

6. One PICH and three S-CCPCH with 40ms TTI for MTCH reception 

The requirement one reflects the case when the UE is in Idle mode, or URA_PCH, CELL_PCH state and MBMS 
reception is not ongoing and requirement five and six are for the case that MBMS reception is ongoing in Idle mode, or 
URA_PCH, CELL_PCH state. 

The requirement two reflects the case when the UE is in CELL_EACH state and MBMS is reception not ongoing and 
requirement three and four are for the case when MBMS reception is ongoing respectively. 

The requirement for the number of simultaneous S-CCPCHs for MTCH reception includes those S-CCPCHs for which 
combining is performed. 

When MBMS ptm reception is ongoing, the UE is required to periodically monitor the MCCH, which may be mapped 
onto a different S-CCPCH from MTCH, and a different S-CCPCH than the R"99 EACH when the UE is in 
CELL_EACH state. However this does not increase the requirement for the number of S-CCPCHs to be simultaneously 
received by the UE. 

The ability of the UE to receive DPCH/HS-PDSCH simultaneously with S-CCPCH carrying MTCH/MCCH is subject 
to UE capability. 

The minimum MBMS bit rate that all MBMS capable UEs shall support is to be defined [12]. 

Eor EDD, the UE shall support selective combining and soft combining. Eor TDD, the UE shall support selective and 
soft combining. 

The standard may restrict further the UE implementation options by defining certain capability combinations. 

If the UE is supporting MBMS ptm reception in CELL_DCH state, it shall have capability to acquire MCCH 
configuration from BCCH after handover procedure, and after that receive MCCH and MTCH. 

7.3 MBMS Reception 

The following descriptions add MBMS specific processes to be considered for each RRC State/Mode. 

The BCCH contains information regarding the MCCH, while the latter contains information on the MTCH. 

In the sub-sections below, how and when the UE reads the MCCH is not described as periodic MCCH transmission is 
described in section 5.2.3. 

The reception of multiple MBMS services simultaneously is subject to UE capability; selection principles between 
MBMS services are defined in section 5.2.8. The specific actions related to MBMS session repetition are specified in 
section 5.2.7. 

7.3.1 MBMS Reception in RRC Idle Mode 

In idle mode, the UE shall: 

- if the UE supports MBMS and 
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- if the UE has activated an MBMS service and there is an ongoing session for this service in the cell where the UE 
is situated, i.e. MTCH and MCCH are available 

- act on RRC messages received on MCCH and: 

- if the MBMS service requires the establishment of an RRC Connection due to counting response or due to the 

utilisation of p-t-p transfer mode for the MBMS service: 

- inform upper layers that the MBMS Service requires the establishment of an RRC Connection. 

- if the MBMS service does not require the establishment of an RRC Connection : 

- listen to the common transport channel on which the MTCH is mapped. 

- if the UE determines that a neighbouring cell is suitable for selective or soft combining and the UE has valid 

MBMS NEIGHBOURING CELL INFORMATION of that cell: 

- performs selective or soft combining of MTCH between the selected cell and the neighbouring cell. 

7.3.2 MBMS Reception in RRC Connected Mode: URA_PCH state 

In URA_PCH, the UE shall: 

- if the UE supports MBMS and 

- if the UE has activated an MBMS service and there is an ongoing session for this service in the URA where the UE 
is situated, i.e. MTCH and MCCH are available 

- act on RRC messages received on MCCH, 

- if on the MCCH it is indicated that the MBMS service in the cell requires a counting response or is due to 

the utilisation of p-t-p transfer mode for the MBMS service: 

- initiate a cell update procedure, for sending MBMS COUNTING RESPONSE, or MBMS P-T-P 

MODIFICATION REQUEST signalling flow. The cause to be used in the cell update procedure is 
defined in [13]. 

- for each MBMS service that the UE has activated and where transmission on a MTCH is indicated in the 

MCCH, listen to the common transport channel on which the MTCH is mapped, 

- if the UE determines that a neighbouring cell is suitable for selective or soft combining and the UE has valid 

MBMS NEIGHBOURING CELL INFORMATION of that cell 

- performs selective or soft combining of MTCH between the selected cell and the neighbouring cell. 

7.3.3 MBMS Reception in RRC Connected Mode: CELL_PCH state 

In CELL_PCH, the UE shall: 

- if the UE supports MBMS and 

- if the UE has activated an MBMS service and there is an ongoing session for this service in the cell where the UE 
is situated, i.e. MTCH and MCCH are available 

- act on RRC messages received on MCCH 

- if on the MCCH it is indicated that the MBMS service in the cell requires counting response or is due to the 

utilisation of p-t-p transfer mode for the MBMS service: 

- initiate a cell update procedure for sending MBMS COUNTING RESPONSE, or MBMS P-T-P 
MODIFICATION REQUEST signalling flow. The cause to be used in the cell update procedure is 
defined in [13]. 

- listen to the common transport channel on which the MTCH is mapped. 
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- if the UE determines that a neighbouring cell is suitable for selective or soft combining and the UE has valid 

MBMS NEIGHBOURING CELL INFORMATION of that cell 

- performs selective or soft combining of MTCH between the selected cell and the neighbouring cell. 

7.3.4 MBMS Reception in RRC Connected Mode: CELL_FACH state 

In CELL_FACH, the UE shall: 

- if the UE supports MBMS and 

- if the UE has activated an MBMS service and there is an ongoing session for this service in the cell where the UE 
is situated, i.e. MTCH and MCCH are available 

- act on RRC messages received on MCCH 

- if on the MCCH it is indicated that the MBMS service in the cell requires a counting response or is due to 

the utilisation of p-t-p transfer mode for MBMS service: 

- initiate a counting response for sending MBMS COUNTING RESPONSE, or MBMS P-T-P 
MODIFICATION REQUEST signalling flow. 

- listen to the common transport channel on which the MTCH is mapped 

- if the UE determines that a neighbouring cell is suitable for selective or soft combining and the UE has valid 

MBMS NEIGHBOURING CELL INFORMATION of that cell 

- performs selective or soft combining of MTCH between the selected cell and the neighbouring cell. 
NOTE: For UEs in CELL_FACH, UTRAN may decide to send MBMS data over DTCH. 

7.3.5 MBMS Reception in RRC Connected Mode: CELL_DCH state 

In CELL_DCH, the UE shall, 

- if the UE supports MBMS and 

- if the UE has activated an MBMS service and there is an ongoing session for this service in the cell where the UE 
is situated, i.e. MTCH and MCCH are available and 

- if the UE has the capabilities: 

- act on RRC messages received on MCCH 

- listen to the common transport channel on which the MTCH is mapped. 

- if the UE determines that a neighbouring cell is suitable for selective or soft combining and the UE has valid 

MBMS NEIGHBOURING CELL INFORMATION of that cell and UE has capability 

- performs selective or soft combining of MTCH between the selected cell and the neighbouring cell. 
NOTE: For UEs in CELL_DCH, UTRAN may decide to send MBMS data over DTCH 



8 UTRAN Signalling Flows for MBMS 

8.1 MBMS Higin Level Signalling Scenarios 
8.1.1 Session start 

Upon receiving a session start indication from CN, UTRAN initiates the session start sequence to allocate radio 
resources to UEs for receiving the MBMS content. As part of this sequence, UTRAN may apply the counting procedure 
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(counting the number of idle mode, URA_PCH, CELL_PCH and CELL_FACH state UEs) to decide whether to use the 
p-t-m or p-t-p transfer mode. For MBMS Broadcast mode, the appHcability of the counting procedure for a service is 
indicated by the CN. 

The Figure 8.1.1 shows an example of a possible session start sequence. 



UE 



UTRAN 



1 . Notification for session start 



2. MBIVIS RB (IVITCH, DTCH) establisliment 



3. IVIBIVIS data transfer 



Figure 8.1 .1 : Session start 

In general, the session start sequence involves the following steps: 

• In case UTRAN applies counting to determine the most optimal transfer mode the following steps are performed: 

o UTRAN sets the correct MBMS Notification Indicator (NI) and sends the MBMS CHANGE 

INFORMATION and the MBMS ACCESS INFORMATION including service ID, the session ID if 
received from the CN, and access probability on MCCH. 

o Upon DRX wakeup, UEs in idle mode as well as UEs in CELL_PCH, URA_PCH and CELL _FACH not 
receiving an MBMS service provided in p-t-m transfer mode evaluate the MBMS NI and if set, read the 
MBMS CHANGE INFORMATION from MCCH at beginning of the modification period. UEs in idle 
mode as well as UEs in CELL_PCH, URA_PCH and CELL _FACH receiving an MBMS service provided 
in p-t-m transfer mode read the MBMS CHANGE INFORMATION directly. If service Id of activated 
MBMS service and session ID that the UE has not received is indicated in MBMS CHANGE 
INFORMATION UEs continue reading the rest of MCCH information. Upon receiving the MBMS 
ACCESS INFORMATION including access probability, UEs in idle mode or URA_PCH, CELL_PCH, 
and CELL_FACH state for which the probability check passes, initiate counting response. UTRAN counts 
the UEs interested in the MBMS service combining the UE linking from CN and received counting 
responses from UEs. 

o In the case that no UE is counted as present in the cell then UTRAN may decide not to provide any RB for 
the service in the cell. 

o In case a pre- defined threshold is reached, UTRAN applies the p-t-m RB establishment procedure 
specified below. Otherwise, UTRAN may repeat the MBMS ACCESS INFORMATION a number of 
times, using different probability values. If the threshold is not reached, UTRAN applies the p-t-p RB 
establishment procedure 

• In case UTRAN selects the p-t-m RB establishment procedure: 

o UTRAN configures MTCH and updates MCCH (MBMS SERVICE INFORMATION and MBMS 

RADIO BEARER INFORMATION) by including the service ID, the session ID if received from the CN, 
and p-t-m RB information for the concerned MBMS service 

o In case p-t-m RB establishment is not preceded by counting, UTRAN sets the correct MBMS Notification 
Indicator (NI) and sends MBMS CHANGE INFORMATION. 
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o UTRAN sends the MBMS dedicated notification message including the service ID and cause= session 
start on DCCH to inform UEs in CELL_DCH that are not receiving an MBMS service provided using p-t- 
m transfer mode 

o In case p-t-m RB establishment is preceded by counting, UEs read MCCH at the pre- defined time(s) to 
acquire the MBMS SERVICE INFORMATION and MBMS RADIO BEARER INFORMATION 

o In case p-t-m RB establishment is not preceded by counting, Upon DRX wakeup, UEs not receiving 
MTCH evaluate the MBMS NI and if set, read MCCH at beginning of modification period to acquire 
MBMS CHANGE INFORMATION. UEs in idle mode as well as UEs in CELL_PCH, URA_PCH and 
CELL _FACH receiving an MBMS service provided in p-t-m transfer mode read the MBMS CHANGE 
INFORMATION directly. If service Id of activated MBMS service and session ID that the UE has not 
received is indicated in MBMS CHANGE INFORMATION UEs continue reading the rest of MCCH 
information to acquire the MBMS SERVICE INFORMATION and MBMS RADIO BEARER 
INFORMATION 

o UEs that are incapable of receiving the MTCH for the session that is started in parallel to the existing 
activity notify the user. This enables the user to choose between the ongoing activity and the new MBMS 

service 

o Upon receiving MBMS dedicated notification with cause= session start, UEs in CELL_DCH that are 
incapable of receiving the MCCH and the corresponding MTCH in parallel to the existing activity notify 
the user. This enables the user to choose between the ongoing activity and the new MBMS service. If the 
user decides to receive the new MBMS service, the UE shall read MCCH to acquire the MBMS SERVICE 
INFORMATION and MBMS RADIO BEARER INFORMATION. 

o Upon receiving the MBMS SERVICE INFORMATION and the MBMS RB INFORMATION including 
the p-t-m RB information for the concerned MBMS service, the UE starts receiving the p-t-m radio 
bearers 

• In case UTRAN selects the p-t-p RB establishment procedure: 

o UTRAN indicates on MCCH in MBMS CHANGE INFORMATION that MBMS service is provided via 
p-t-p 

o After receiving MBMS CHANGE INFORMATION UEs interested to receive MBMS service, after 
possible service priorisation, request MBMS p-t-p RB establishment by sending MBMS P-T-P 
MODIFICATION REQUEST signalling flow. 

o Furthermore, UTRAN establishes the p-t-p RB by means of appropriate RRC procedures e.g. the RB setup 
procedure 

o UEs establish the p-t-p radio bearers by means of the RRC procedure selected by UTRAN eg. the RB 
setup procedure 

o UTRAN updates MCCH (MBMS SERVICE INFO) to inform UEs joining or entering the cell at a later 
point in time. 



8.1.2 Joining (during a session) 



In case the user wants to join an MBMS service (before or during a session), the UE initiates NAS procedures (e.g. 
MBMS service activation). 

If no session is ongoing upon completion of the joining procedure, the joining procedure is transparent to the AS. 

In case a session using p-t-m transfer mode is ongoing upon completion of the joining procedure, the UE may initiate 
reception of the p-t-m radio bearers. In case the ongoing session applies p-t-p transfer mode, UTRAN may establish the 
p-t-p radio bearers. UTRAN would do this upon receiving a UE linking indication from CN, which normally follows 
the joining. As a result of the UE linking, UTRAN may decide to change the transfer mode from p-t-p to p-t-m. This 
change of transfer mode is out of the scope of this sequence (to be covered by a separate sequence). 

The Figure 8.L2 shows an example of a possible joining sequence. 
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UE 



1. Joining (NAS) 



UTRAN 



2. Initiate reception of PTIVI RBs 



3. IVIBIVIS data transfer, PTM 



Figure 8.1.2: Joining with continuation of p-t-m 

In general, the joining sequence involves the following steps: 

• UEs in idle mode first perform RRC connection establishment, while UEs in CELL_PCH and URA_PCH first 
perform cell update 

• UEs initiate the joining procedure (NAS) 

• In case UTRAN continues to use the p-t-m transfer mode: 

o UTRAN sends the MBMS dedicated notification message on DCCH including the service ID and cause= 
session ongoing to inform UEs in CELL_DCH 

o Upon receiving MBMS dedicated notification with cause= session ongoing, UEs in CELL_DCH that are 
incapable of receiving the MCCH and the corresponding MTCH in parallel to the existing activity notify 
the upper layer. This enables the user to choose between the ongoing activity and the new MBMS service. 
If the user chooses to receive the new MBMS service or if the UE in Cell_DCH is capable of receiving 
MCCH and MTCH in parallel to the existing activity, the UE shall read MCCH to acquire the MBMS 
SERVICE INFORMATION and MBMS RADIO BEARER INFORMATION from MCCH. 

o Upon acquiring the MBMS SERVICE INFORMATION and the MBMS RADIO BEARER 

INFORMATION including the p-t-m RB information for the concerned MBMS service, the UE starts 
receiving the p-t-m radio bearers 

• In case UTRAN continues using the p-t-p transfer mode: 

o UTRAN establishes the p-t-p RB by means of appropriate RRC procedures eg. the RB setup procedure 

o UEs establish the p-t-p radio bearers by means of the RRC procedure selected by UTRAN eg. the RB 
setup procedure. 

8.1.3 Recounting 

During a p-t-m MBMS session, UTRAN may perform re- counting to verify if p-t-m is still the optimal transfer mode. 
The purpose of the re- counting procedure is to count the number of idle mode, URA_PCH, CELL_PCH, and 
CELL_FACH state UEs that have joined a specific service. As a result of this procedure, UTRAN may decide to change 
the transfer mode from p-t-m to p-t-p. This change of transfer mode is outside the scope of this sequence (to be covered 
by a separate sequence). 

The Figure 8.1.3 shows an example of a possible recounting sequence. 
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UE 



MBMS data transfer, PTM 



1 . Notification for re-counting 



UTRAN 



2: Act based on messages received on 
IVICCH 



IVIBIVIS data transfer, PTM 



Figure 8.1.3: Recounting with continuation of p-t-m 

In case UTRAN applies re- counting to determine the most optimal transfer mode, the following steps are performed: 

• UTRAN sends the MBMS CHANGE INFORMATION and the MBMS ACCESS INFORMATION including 
service ID, and access probability on MCCH 

• UEs in idle mode as well as UEs in CELL_PCH, URA_PCH and CELL _FACH receiving an MBMS service 
provided in p-t-m transfer mode read the MBMS CHANGE INFORMATION at the beginning of each 
modification period. If service Id of activated MBMS service is indicated in MBMS CHANGE INFORMATION 
UEs continue reading the rest of MCCH information. 

• Upon receiving the MBMS ACCESS INFORMATION including access probability, UEs in idle mode or 
URA_PCH, CELL_PCH and CELL_FACH state for which the probability check passes, initiate counting response. 

• UTRAN counts the UEs interested in the MBMS service combining the UE linking from CN and received counting 
responses from UEs. 

• In the case that no UE is counted as present in the cell then UTRAN may decide not to provide any RB for the 
service in the cell. 

• In case a pre- defined threshold is reached, UTRAN continues using the p-t-m transfer mode. Otherwise, UTRAN 
may repeat the MBMS ACCESS INFORMATION a number of times, using different probabiHty values. If the 
threshold is not reached, UTRAN switches transfer mode from p-t-m to p-t-p 

• In case UTRAN continues using the p-t-m transfer mode, it may return UEs that responded to counting back to idle 
mode by releasing the RRC connection. 
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8.1.4 Session Stop 

UTRAN may apply the session stop procedure to inform UEs that the end of MTCH transmission concerns the end of a 
session rather than just an idle period. The purpose of the procedure is to reduce the UE power consumption. 

The Figure 8. 1 .4 shows an example of a possible session stop sequence. 



UE 



UTRAN 



1 . Termination of MBMS data transfer, PTM 



2. Notification for session stop 



Figure 8.1.4: Session stop 

In case UTRAN provides the service p-t-m, the session stop sequence involves the following steps: 

• UTRAN updates the MBMS CHANGE INFORMATION, MBMS SERVICE INFORMATION and the MBMS 
RADIO BEARER INFORMATION including the service ID and the explicit radio bearer release indicator. 
UTRAN updates MCCH (MBMS SERVICE INFORMATION) to inform UEs joining or entering the cell in a later 
point of time. 

• UEs in idle mode as well as UEs in CELL_PCH, URA_PCH and CELL _FACH receiving an MBMS service 
provided in p-t-m transfer mode read the MBMS CHANGE INFORMATION at the beginning of the each 
modification period. If service Id of activated MBMS service is indicated in MBMS CHANGE INFORMATION 
UEs continue reading the rest of MCCH information. 

• Upon receiving this information the UE stops receiving the MTCH 

In case UTRAN provides the service p-t-p, the session stop sequence involves the following steps: 

• UTRAN releases the p-t-p radio bearers and updates MCCH (MBMS SERVICE INFO) to inform UEs joining or 
entering the cell at a later point in time. 

8.2 MBMS RNC Signalling Flows 
8.2.1 IVIBIVIS Session Start procedure 



RNC 




CN 




4 [F 


^ANAP] MBMS SESSION STAF 


^T 






^ REQUEST 

[RANAP] MBMS SESSION START ^ 








RESPONSE 


w 





Figure 8.2.1 : lUIBIUIS Session Start procedure. Successful operation. 



£75/ 



3GPP TS 25.346 version 6.10.0 Release 6 



36 



ETSI TS 125 346 V6.10.0 (2007-03) 



The MBMS Session Start procedure is initiated by the CN when an MBMS Session is started. The MBMS SESSION 
START REQUEST is sent to each RNC that is connected to the CN (in case of lu-flex the RNC may receive more than 
one MBMS SESSION START REQUEST message). 

The MBMS SESSION START REQUEST contains the MBMS Service Id, and optionally the MBMS Session ID, 
MBMS Bearer Service Type and the MBMS Session Attributes (MBMS Service Area Information, QoS parameters...) 
It may also include a list of RAs which lists each RA that contains at least one PMM-IDLE UE that has activated the 
service. 

MBMS Session Start procedure also provides the MBMS lu Data Bearer Establishment functionality. In case of lu-flex 
the RNC shall not establish more than one MBMS lu bearer for a certain service towards a pool area and shall inform 
the respective CN nodes accordingly. 



8.2.2 MBMS Session Update procedure 



RNC 




CN 




[RANAP] MBMS SESSION UPDATE 






^ REQUEST 

[RANAP] MBMS SESSION UPDATE ^ 








RESPONSE 


w 





Figure 8.2.2: MBMS Session Update procedure. Successful operation. 

The MBMS Session Update procedure is initiated by the CN when an MBMS Session is ongoing and SGSN notices 
that there is a need to update the list of RAs. The MBMS SESSION UPDATE REQUEST contains the MBMS Service 
Id, and e.g. List of RAs with PMM Idle UEs.. 

8.2.3 MBMS Session Stop procedure 



RNC 








CN 






[ 


RANAP] MBMS SESSION STO 


P 










REQUEST 
[RANAPl MBMS SESSION STOP 












RESPONSE 




w 





Figure 8.2.3: MBMS Session Stop procedure. 

This signalling flow depicts the MBMS Session Stop procedure. 

This procedure is initiated by the CN to the RNCs with an ongoing MBMS session, when no more data will be sent for 
that MBMS service for some period of time. 

The MBMS Session Stop procedure also provides the MBMS lu Data Bearer Release functionality. 
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8.2.4 RNC Registration procedure 



RNC 




CN 




[RANAP] MBMS REGISTRATION 






REQUEST ^ 
[RANAP] MBMS REGISTRATION 






^ 


RESPONSE 







Figure 8.2.4: MBMS Registration procedure. 

This signalling flow depicts the MBMS Registration procedure. 

This procedure is initiated by the RNC in the case that the RNC is not SRNC for any UE that has joined the MBMS 
Service, but this RNC is DRNC for PMM-CONNECTED UEs that have joined the MBMS Service and there is no 
MBMS Service Context for the MBMS Service in this RNC. 

This procedure shall be initiated by the DRNC, as soon as a UE link is received over the lur and there exists no MBMS 
Service Context for the MBMS service for which the UE link is received. 

8.2.5 RNC De-Registration procedure 



RNC 




CN 




[Ry 


^NAP] MBMS DE-REGISTRAT 


ON^ 






REQUEST 
^ [RANAP] MBMS DE-REGISTRATION 






^ 


RESPONSE 







Figure 8.2.5: RNC MBMS De-Registration procedure. 

This signalling flow depicts the RNC De-Registration procedure. This procedure is initiated by the RNC towards the 
CN node it was registered to in case the RNC is not acting as a Serving RNC for any UE that has activated the MBMS 
Service and has ceased to act as a Drift RNC for UEs which has activated an MBMS service. 

8.2.6 CN De-Registration procedure 



RNC 




CN 




4 [R' 


SiNAP] MBMS DE-REGISTRAT 


ON 






^ REQUEST 

[RANAP] MBMS DE-REGISTRATION ^ 








RESPONSE 


w 





Figure 8.2.6: CN MBMS De-Registration procedure. 

This signalling flow depicts the CN De-Registration procedure. 

This procedure is initiated by the CN in order to inform the RNC that a certain MBMS Service is no longer available. 
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8.2.7 MBMS Channel Type Switching over Uu 



UE 




CRNC 




SRNC 










MBMS CONTROL (p-t-p) 
















4 

^ 


MBMS DATA (p-t-m) 
MBMS DATA (p-t-m) 








ri 
















CRNC determines to 
switch channel type 
from ptm to ptp 












1 












MBMS Channel Type Reconfiguration Signalling over lur 






[RRC] RB SETUP 






SRNC decides whether to 

perform channel type 

switching to p-t-p or not 
















[RRC] RB SETUP COMPLETE 








M 


MBMS Data (p-t-p) 







Figure 8.2.7: Channel type switching signalling flow from p-t-m to p-t-p. 

The CRNC is responsible for the decision regarding having p-t-m transmission or no p-t-m transmission in a cell for a 
specific MBMS service. The CRNC informs all the SRNCs having UEs in that cell about its decision. The SRNC is the 
RNC controlling the RRC connection and RBs to a specific UE. In the example shown, the CRNC decided to no longer 
use p-t-m, then the SRNC decided to perform channel type switching to deliver the MBMS service over DTCH mapped 
on a dedicated channel. The RB SETUP message contains the MBMS Service Id. It is PES whether the SRNC always 
follows the CRNC's request or not. 

NOTE: the channel type switching in this case includes a change of both transport and logical channels. 

8.2.8 MBMS UE Uniting 



SRNC 



CN 



[RANAP] MBMS UE LINKING 
REQUEST 



[RANAP] MBMS UE LINKING 
RESPONSE 



Figure 8.2.8: MBMS UE linking signalling flow 

This signalling flow is only applicable for handling UEs in PMM-CONNECTED mode with activated MBMS Services. 

The signalling flow is used to link a specific UE to one or several MBMS service contexts in the SRNC. The MBMS 
UE LINKING REQUEST message contains the whole Hst of MBMS Service Ids and MBMS PTP RAB IDs (e.g. 
mapped from NS APIs) activated by the UE. If there has not been an MBMS service context related to an MBMS 
Service Id then SRNC creates an MBMS service context as a result of this procedure. 



£75/ 



3GPP TS 25.346 version 6.10.0 Release 6 



39 



ETSI TS 125 346 V6.10.0 (2007-03) 



8.2.9 MBMS UE De-Linking 



SRNC 



CN 



[RANAP] MBMS UE DE-LINKING 
REQUEST 



[RANAP] MBMS UE DE-LINKING 
RESPONSE 



Figure 8.2.9: MBMS UE De-linking signalling flow 

This signalling flow is only applicable for handling UEs in PMM-CONNECTED mode with activated MBMS Services. 

The signalling flow is used to remove a specific UE from one or several MBMS service context in the SRNC. The 
MBMS UE DE-LINKING REQUEST message contains the list of MBMS Service Ids de-activated by the UE. 

8.2.10 MBMS Service Id Request 



UE 



RNC 



lu-cs connection establishment 



MSC 



RANAP]COMMON ID 



[RANAPJMBMS SERV CE ID REQ 



[RANAP] MBMS SERVIjCE ID RESPONSE 

< 



SGSN 



Figure 8.2.10: MBMS Service Id list over lu signalling flow 

This signalling flow is applicable for handling MBMS to UEs in RRC-Connected, PMM-IDLE state. The list of MBMS 
services the user has joined is sent over lu. 

The purpose of this signalling flow is to perform UE linking for a RRC connected, PMM idle user. The UE provides an 
indication that the user has joined at least one MBMS service and the PS Domain specific IDNNS (the message that 
would carry this information is FES) whenever an lu-cs connection is established and the UE is PMM idle (that is there 
is no lu-ps connection), The RNC requests the MBMS services the UE has joined from the SGSN (or the SGSN the UE 
is attached to in case of lu-flex) using a connectionless procedure. The MBMS SERVICE ID REQ contains the IMSI of 
the UE. The SGSN response contains the full list of MBMS services the user has joined. 

The MBMS service list is then stored in the RNC. The list is deleted when the UE moves to RRC idle and the RRC 
context is removed in the RNC. 
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8.2.1 1 MBMS Attach/Detach over lur 



CRNC 


[RNSAP] MBMS ATTACH 
REQUEST 


SRNC 




^ 








[RNSAP] MBMS ATTACH 
RESPONSE 










w 





Figure 8.2.1 1-1 : MBMS attach request signalling flow: Successful Operation. 

This signalling flow is only applicable for handling UEs in RRC connected mode with activated MBMS Services. 

The piupose of this signalling flow is 

to either allow the CRNC to add one or several new UEs to the total number of UEs in a given cell using 
one or several MBMS services. The MBMS ATTACH REQUEST then contains the Cell Id of the new 
cell (may contain the URA Id of the new URA for UEs in URA_PCH state), the whole list of affected 
MBMS Service Ids and a UTRAN specific UE Identification if necessary. 

or to allow the SRNC to inform the DRNC in which URA notifications for MBMS Services have to be 
sent. The MBMS ATTACH REQUEST then contains a list of URAs and the corresponding MBMS 
Services. 



CRNC 


[RNSAP] MBMS DETACH 
REQUEST 


SRNC 




^ 








[RNSAP] MBMS DETACH 
RESPONSE 










w 





Figure 8.2.11-2: MBMS detach request signalling flow: Successful Operation. 

This signalling flow is only applicable for handling UEs in RRC connected mode with activated MBMS Services. 
The purpose of this signalling flow is 

- to either allow the CRNC to decrease the total number of UEs receiving one or several MBMS service in 
a given cell. The MBMS DETACH REQUEST contains the Cell Id of the old cell (may contain the URA 
Id of the old URA for UEs in URA_PCH state), the whole list of affected MBMS Service Ids and a 
UTRAN specific UE Identification if necessary. 

- or to allow the SRNC to inform the DRNC in which URA there is not anymore a need to send 
notifications for MBMS Services due to the presence of UEs in URA_PCH. The MBMS DETACH 
REQUEST then contains a list of URAs and the corresponding MBMS Services 

8.2.12 MBMS Channel Type Reconfiguration over lur 

These signalling flows need further study. 
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DRNC 




SRNC 




[RNSAP] MBMS CHANNEL TYPE 






RECONFIGURAITON INDICATION 






[RNSAP] MBMS CHANNEL TYPE 






RECONFIGURATION CONFIRMATION 















Figure 8.2.12: Channel Type Reconfiguration signalling flow: Successful Operation. 

This signalling flow is only applicable for handling MBMS UEs in RRC connected mode. 

The purpose of this signalling flow is that the CRNC informs the selected channel type to the SRNCs used in a cell 
under the CRNC. The MBMS CHANNEL TYPE RECONFIGURATION INDICATION contains a list of U-RNTI, 
Channel type and MBMS Service Id corresponding to the UEs connected to the SRNC. 



8.2.13 Information Exchange over lur 



These signalling flows is used by the DRNC to acquire the MBMS related information for MBMS service identified by 
TMGI. 



DRNC 




SRNC 




[RN 


SAP] INFORMATION EXCHAN 
INITIATION REQUEST 


GE 






w 

[RNSAP] INFORMATION EXCHANGE 
INITIATION RESPONSE 






^ 









Figure 8.2.13: Information Exchange Initiation signalling flow: Successful Operation. 

The purpose of this signalling flow is that the DRNC request the APN and IP multicast address for an MBMS service. 
The INFORMATION EXCHANGE INITIATION REQUEST includes the TMGI for which the APN and IP multicast 
address are requested. In the INFORMATION EXCHANGE INITIATION RESPONSE message, the corresponding 
APN and IP multicast address are included. 

8.2.14 MBMS RAB Establishment Indication 
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RNC 




CN 




[RANAP] MBMS RAB ESTABLISHMENT 
INDICATION 















Figure 8.2.14: MBMS RAB Establishment Indication procedure 



This signalling flow is used by the RNC to indicate to the CN the establishment of the MBMS RAB corresponding to 
the MBMS lu signalling connection. 

When the RNC decides not to establish an MBMS lu bearer, for a particular MBMS service, during MBMS Session 
Start procedure, for example the RNC does not control any contained in MBMS Service Area Information and the RNC 
does not belong to any of the RA in a list of RAs which lists each RA that contains at least one PMM-IDLE UE but 
later when a UE linking (via lu or lur) is performed or as a result (p-t-p decision) of channel type reconfiguration in 
another RNC, the RNC establishes the lu bearer and uses this procedure to inform the CN that an lu bearer has been 
established. 

If lu-Flex is active, the selection of the CN node is implementation dependant. 

The MBMS RAB ESTABLISHMENT INDICATION message contains the Transport Layer Address IE and the lu 
Transport Association IE. 



8.2.15 MBMS RAB Release 



RNC 


RANAP] MBMS RAB RELEASE 
REQUEST 


CN 




[ 








[ 


RANAP] MBMS RAB RELEASE 

















Figure 8.2.15: MBMS RAB Release Request procedure. 

This signalling flow is used by the RNC to indicate to the CN to request the release of an MBMS RAB. 

At reception of the MBMS RAB RELEASE REQUEST message the CN should initiate the release of all MBMS 
resources related to the lu connection without releasing the lu signalling connection. 

The RNC shall at reception of MBMS RAB RELEASE initiate the release of the related MBMS RAB resources. 

The MBMS RAB release may be initiated e.g. for the following reasons (unexhausted): 

There are lack of rafio resource in UTRAN and RNC decided to pre-empt an MBMS RAB for a on-going 
MBMS session based on Allocation/Retention Priority 
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When there are no UEs interested in MBMS consuming radio resources in cells under the RNC or the RNC is 
controlling UEs in cells under another RNC; 

In case of channel type switching from ptp to ptm in cells under control of another RNC in its role of DRNC; 

There are no cells under the RNC which are part of the RA List Of Idle UEs if received. 



8.3 MBMS Uu Signalling Flows 

8.3.1 Broadcast of MBMS System Information 



UE 



CRNC 



MBMS SYSTEM INFORMATION 



Figure 8.3.1 : Broadcast of MBMS system information. 

This signalling flow is applicable for handUng MBMS to UEs in PMM IDLE and PMM-CONNECTED mode. 

The purpose of the signalling flow is for UTRAN to broadcast MBMS system information to UEs using the BCCH. The 
MBMS SYSTEM INFORMATION shall be repeatedly transmitted after its first transmission. Upon receiving the first 
MBMS SYSTEM INFORMATION, the UE shall estabhsh the radio bearer carrying an MCCH. 

The MBMS SYSTEM INFORMATION includes: 

- MCCH schedule information (access info, repetition and modification periods) 

- Configuration of a radio bearer carrying an MCCH 

More information may be included in the MBMS SYSTEM INFORMATION. 

8.3.2 MBMS Service Information 



UE 



CRNC 



MBMS SERVICE INFORMATION 



Figure 8.3.2: MBMS service information signalling flow 

This signalling flow is applicable for handling MBMS to UEs in PMM IDLE and PMM-CONNECTED mode. 

The purpose of the signalling flow is for RNC to inform UEs of all of MBMS services available in one cell. The 
MBMS SERVICE INFORMATION shall be transmitted periodically on MCCH to provide an indication of the status of 
the MBMS service in the cell and to support mobility. 

The MBMS SERVICE INFORMATION contains MBMS service ids, optionally the MBMS Session ID, and an 
indication of the service status in the cell i.e. whether it is provided by p-t-m or p-t-p bearers or whether explicit release 
is indicated. The MBMS service ids indicate the MBMS services which are being served in the cell or the MBMS 
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services which can be served if the UE requests it. P-t-m indication indicates that the MBMS service is on p-t-m in the 
cell, thus it informs the UE of the need of reception of the MBMS RADIO BEARER INFORMATION. 



8.3.3 MBMS Radio Bearer Information 



UE 


MBMS RADIO BEARER 
INFORMATION 


CRNC 




^ 








^ 









Figure 8.3.3: MBMS radio bearer information signalling flow 

This signalling flow is applicable for handling MBMS to UEs in IDLE and PMM-CONNECTED mode. 

The purpose of the signalling flow is for the RNC to inform UE(s) regarding the MTCH radio bearer information. 
MBMS RADIO BEARER INFORMATION is only available for p-t-m transmission. MBMS RADIO BEARER 
INFORMATION shall be transmitted periodically on MCCH to support mobility in the MBMS service. 

MBMS RADIO BEARER INFORMATION includes MBMS Service Id, radio bearer, transport channel and physical 
channel information per MBMS service. 

8.3.4 MBMS Access Information 



UE 



CRNC 



MBMS ACCESS INFORMATION 



Figure 8.3.4: MBMS Access Information signalling flow 

This signalling flow is applicable for handling MBMS UEs in IDLE mode or URA_PCH, CELL_PCH, CELL_FACH 

state. 

The purpose of the signalling flow is for the RNC to inform UE(s) interested in a particular service of the potential need 
to make an MBMS Counting Response i.e. establish an RRC connection or make a cell update. The MBMS ACCESS 
INFORMATION is transmitted during counting and re-counting on MCCH. The MBMS ACCESS INFORMATION 
includes, for each service for which counting is required, the MBMS service identifier, probability factors for idle and 
connected modes and an indication of the connected mode states to which the signalling flow applies. 
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8.3.5 MBMS Neighbouring Cell Information 



UE 


/IBMS NEIGHBOURING CELL 
INFORMATION 


CRNC 












^ 









Figure 8.3.5: MBMS Neighbouring Cell Information signalling flow 

This signalling flow is applicable for handling MBMS to UEs in PMM IDLE and CONNECTED mode. 

The purpose of the MBMS NEIGHBOURING CELL INFORMATION signalling flow is for the UTRAN to inform to 
UEs of the MTCH configuration of the neighbouring cells which are available for selective combining. In case of partial 
soft combining, the MBMS NEIGBOURING CELL INFORMATION contains the LI -combining schedule, which 
indicates when the soft combining is applicable between the specific S-CCPCH of the cell and the specific S-CCPCH of 
the neighbouring cell. With MBMS NEIGHBOURING CELL INFORMATION the UE is able to receive MTCH 
transmission from neighbouring cell without reception of the MCCH of that cell. The MBMS NEIGHBOURING CELL 
INFORMATION shall be repeatedly transmitted on MCCH when selective or soft combining is utilized in the MBMS 
p-t-m transmission in the given cell group. 

8.3.6 MBMS Joined Indication 



UE 



SRNC 



MBMS JOINED INDICATION 



Figure 8.3.6: MBMS joined indication signalling flow 

This signalling flow is applicable for handling MBMS to UEs in RRC-Connected, PMM-IDLE state. The MBMS 
JOINED INDICATION is sent over the DCCH. 

The signalling flow is initiated by the UE after entering RRC-Connected, PMM-IDLE state. The purpose of the signalling flow 
is to enable the UE to inform the SRNC that the user has joined at least one MBMS service. The SRNC requests the MBMS 
services the UE has joined from the SGSN as defined in subclause 8.2.10. 

In SRNC relocation this information is transmitted from source RNC to target RNC. 

NOTE: If SRNC has valid linking information the complete service list of activated services is also transmitted 
from source RNC to target RNC in SRNC relocation. 
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8.3.7 MTCH Scheduling Information 



UE 


MTCH SCHEDULING 
INFORMATION 


CRNC 





















Figure 8.3.7: MTCH scheduling information. 

This signalling flow is applicable for handling MBMS to UEs in PMM IDLE and CONNECTED mode. 

The purpose of the signalling flow is to enable UEs to perform discontinuous reception of MTCH. The UE may 
discontinuously receive MTCH based on scheduling information indicated by the MTCH SCHEDULING 
INFORMATION. This signalling is transmitted on MSCH mapped on SCCPCH carrying MTCH. The MTCH 
SCHEDULING INFORMATION is signalled on each MSCH repetition period. The MSCH repetition period and the 
offset from the MCCH modification period are indicated on MCCH. In case of soft combining, the MSCH repetition 
period is same for all soft combinable S-CCPCH. The scheduling information allows to cover different periods for 
different MBMS services. 

The MTCH SCHEDULING INFORMATION includes for each service: 

- MBMS service Id (the actual coding is defined in stage-3). 

- Beginning and duration of MBMS data transmission (one contiguous block or more is defined in Stage-3). 

- Duration can be infinite (no DTX). This option could be signalled in the MCCH (Stage-3 definition). 

-Indication of no MBMS data transmission for either this period or several consecutive periods (a period is expressed in 
MSCH repetition period). 



8.3.8 MBMS Change Information 
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MBMS CHANGE 
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CRNC 
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^ 









Figure 8.3.8: MBMS change information. 

This signalling flow is applicable for handling MBMS to UEs in PMM IDLE and CONNECTED mode. UTRAN 
should transmit this signalling flow in beginning of each modification period on MCCH and repeat it at least in every 
repetition period of that modification period. UE shall read this information flow when detecting that MICH bits set for 
a service that UE has activated, or periodically at the begin of each modification period when receiving MTCH. 

The purpose of the signalling flow is to indicate MBMS services whose MCCH information is changed in that 
modification period. The content of MBMS CHANGE INFORMATIO shall be minimized, so that the MCCH reading 
time for the UEs, activated MBMS service whose MCCH information is not modified on that modification period, is 
minimized. 

The MBMS CHANGE INFORMATION includes: 

The MBMS service Ids for which MCCH information is modified on that modification period. 
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8.3.9 MBMS P-T-P Modification Request 



UE 


MBMS P-T-P 
Modification Request 


SRNC 
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Figure 8.3.9: MBMS P-T-P Modification Request. 

This signalling flow is applicable for handling UEs that are interested to receive MBMS p-t-p RB in PMM IDLE and 
CONNECTED mode. In idle mode, URA_PCH and CELL_PCH states the UE may transmit this signalling flow to 
request the setup of a p-t-p MBMS RB after receiving the indication on MCCH that p-t-p transfer mode is utilised or, in 
CELL_DCH state, to request the release of the p-t-p MBMS RB due to higher priority MBMS service, or to indicate the 
frequency used for transmitting the higher priority service as specified in subclause 5.2.8. This signalling flow is 
transmitted on DCCH or on CCCH dependent upon UE state. 

UEs in idle mode are required to perform RRC connection establishment for sending this information flow. UEs that are 
in URA_PCH or CELL_PCH state are required to make a cell update and UEs that are in CELL_DCH state transmit an 
MBMS MODIFICATION REQUEST message. 

When UTRAN receives this message from the UE, the UTRAN may setup or release the p-t-p MBMS RB by normal 
RB release procedure or , in the case of a preferred frequency being indicated, it may perform inter-frequency HHO. 

The MBMS P-T-P Modification Request message includes the identity of the MBMS service when the service appears 
in the list of MBMS Selected Services. 



8.3.10 MBMS Counting Response 



UE 



CRNC 



MBMS Counting Response 



Figure 8.3.10: MBMS Counting Response. 

This signalling flow is applicable for UEs passing the probability check in counting procedure in idle mode or 
URA_PCH, CELL_PCH or CELL_FACH state. For the UE in idle mode this signalling flow refers to the complete 
RRC connection establishment procedure. For UEs in URA_PCH, CELL_PCH and CELL_FACH state this signalling 
flow refers to cell update procedure. 

The MBMS Counting Response message includes the identity of the MBMS service when the service appears in the list 
of MBMS Selected Services. 
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8.3.1 1 MBMS Selected Services Information 



UE 


MBMS Selected Services 
Information 


CRNC/ 
SRNC 





















This signalling flow is applicable for UEs entering CELL_DCH state. The purpose of the signalling flow is to enable 
the UE to inform the SRNC that the user requires the reception of MBMS Selected Services. When the SRNC is not the 
CRNC of the UE, this signalling flow may interact with the URA linking/de-linking described in sub-clause 5.1.10. 

This signalling flow is also applicable for UEs in CELL_DCH states, when the list of MBMS Selected Services has 
been modified. 

This signalling flow is also applicable for UEs in CELL_PCH, URA_PCH and CELL_FACH states when the list of 
MBMS Selected Services has been modified by the upper layers and the MBMS Service appears in the MCCH of the 
cell and the RNC has indicated in the MBMS GENERAL INFORMATION message that it should be notified of a 
change to this list. If an MBMS Service is contained in the list of MBMS Selected Services but is currently not 
available in the cell, when the service appears on the MCCH the UE does not perform this signalling flow. 

The purpose of the signalling flow is to enable the UE to inform the CRNC that the list of MBMS Selected Services in 
the UE has been modified. 



Security for MBMS 



Ciphering for MBMS multicast data is done between the BM-SC and the UE as defined in [7]. Therefore, for MBMS p- 
t-m data transmissions no radio interface ciphering is applied. 

In case of p-t-p MBMS data transmissions, if the security is activated for the UE the ciphering is also applied for p-t-p 
MBMS data RB as for any other RB of the UE. 



1 Mobility Procedures for MBMS 

One of the requirements in [5] is: "Data loss during cell change should be minimal". Therefore, when the UE receiving 
an MBMS session in idle mode or connected mode (not including CELL_DCH) re-selects between cells, it should be 
possible to provide service continuity to this UE. 

The following mechanism has been identified to minimise the data loss on cell change. 

10.1 Use of Periodical Transmission of IVIBIVIS Critical 
Information 

In this mechanism, the cell periodically transmits an MBMS critical information, informing all MBMS services 
currently configured for p-t-m transmission or p-t-p transmission. If MBMS service is configured for p-t-m 
transmission, the periodical transmission of MBMS critical information may also contain the Radio Bearer information 
corresponding to each MBMS service and Neighbouring cell information. 

If the cell is configured for p-t-p transmission, then the UE would perform a normal RRC connection establishment. 
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1 0.2 UE Actions for Mobility 



The UE mobility between intra frequency cells is not affected by the MBMS reception. The mobility between different 
frequency layers is affected by the Frequency Layer Convergence process as defined in 1 1 .2, if used by the network. 

In CELL_FACH and in CELL_DCH state the RRC operation has priority over MBMS reception, thus UE performs the 
inter frequency and inter RAT measurements as configured by the SRNC. UTRAN should utilize different periodicities 
between MCCH transmissions and CELL_FACH state measurement occasion, such that CELL_FACH state 
measurements and MCCH transmissions are not constantly overlapping for some UE. 

In Idle mode and in CELL_PCH, URA_PCH states the measurements are performed as configured by the network 
based on the Release 5. The MBMS specific measurement occasions to S-CCPCH for UEs in idle mode and in 
CELL_PCH, URA_PCH states are not introduced and measurements have priority over MBMS reception. The usage of 
channel protection (channel coding) to recover some of the lost transport blocks is possible. 

UEs may have DRx occasions for specific MBMS service when UE can stop decoding S-CCPCH and perform 
measurements. DRx occasion are based on scheduling information. 

R'99 standards have some means to reduce need for number of measurements, which can be utilized for MBMS. 

When the UE reselects the cell due to the mobility or returns to on service from out of service, the UE shall acquire the 
MCCH information if the interested MBMS service is available in the selected cell for the reception of the service. The 
service is available when the session has been already started and the service is being served on p-t-p/p-t-m in the cell, 
or the service can be served in the cell if the UE requests it. 

If the MBMS service is available in the cell, the UE will perform an action for the service reception in the cell. For 
example, if the service is on p-t-p, the idle mode UE will initiate RRC connection establishment procedure. Otherwise, 
the UE does not need to perform such an action in the cell. The UE, which moves to the new cell, will operate 
according to the RRC state/mode as follows. 

Whenever the UE moves between p-t-m cells while continuing to receive a service, UE shall receive MCCH 
information in a new cell, which includes an MBMS cell group identity. If a UE moves between cells belong to the 
same MBMS cell group based on the MCCH information, the UE does not need to re- establish RLC entity and re- 
initialise PDCP entity for the service received on MTCH. If a UE moves between cells belong to different MBMS cell 
groups based on the MCCH information, the UE shall re- establish RLC entity and re- initialise PDCP entity for the 
service received on MTCH. 

10.2.1 RRCIdle mode 

Idle mode UE shall: 

if BCCH contains information regarding the MCCH in the new cell: 

- Usten to the MCCH and receive the MBMS SERVICE INFORMATION; 

- if the MBMS SERVICE INFORMATION contains the interested MBMS service-id: 

- if MBMS SERVICE INFORMATION indicates that the service is on p-t-m: 

- receive the MBMS RADIO BEARER INFORMATION and listen to the MTCH; 
else: 

initiate RRC connection establishment procedure and request the setup of MBMS p-t-p RB; 

- if the UE receive the MBMS RADIO BEARER INFORMATION before the MBMS SERVICE 
INFORMATION and; 

- if MBMS RADIO BEARER INFORMATION contains the interested MBMS service id: 

- Usten to the MTCH without the need of receiving the MBMS SERVICE INFORMATION. 
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10.2.2 URA_PCH State 

URA_PCH state UE shall: 

perform URA update procedure if needed; 

if BCCH contains information regarding the MCCH in the new cell: 

- listen to the MCCH and receive the MBMS SERVICE INFORMATION; 

- if MBMS SERVICE INFORMATION contains the interested MBMS service id: 

- if MBMS SERVICE INFORMATION indicates that the service is on p-t-m: 

- receive the MBMS RADIO BEARER INFORMATION and listen to the MTCH; 
else: 

initiate cell update procedure and request to setup the MBMS p-t-p RB; 

- if the UE receive the MBMS RADIO BEARER INFORMATION before MBMS SERVICE 
INFORMATION message and; 

- if MBMS RADIO BEARER INFORMATION contains the interested MBMS service id: 

- Usten to the MTCH without the need of receiving the MBMS SERVICE INFORMATION. 

10.2.3 CELL_PCH 

CELL_PCH state UE shall: 

perform cell update procedure; 

if BCCH contains information regarding the MCCH in the new cell: 

- listen to the MCCH and receive the MBMS SERVICE INFORMATION; 

- if MBMS SERVICE INFORMATION contains the interested MBMS service id and: 

- if MBMS SERVICE INFORMATION indicates that the service is on p-t-m: 

- receive the MBMS RADIO BEARER INFORMATION message and listen to the MTCH. 
else: 

initiate the cell update procedure and request to setup the MBMS p-t-p RB. 

- if the UE receive the MBMS RADIO BEARER INFORMATION before the MBMS SERVICE 
INFORMATION and; 

- if MBMS RADIO BEARER INFORMATION contains the interested MBMS service id: 

- Usten to the MTCH without the need of receiving the MBMS SERVICE INFORMATION. 

10.2.4 CELL_FACH 

CELL_FACH state UE shall: 

perform cell update procedure 

if BCCH contains information regarding the MCCH in the new cell: 

- listen to the MCCH and receive the MBMS SERVICE INFORMATION; 

- if MBMS SERVICE INFORMATION contains the interested MBMS service id and; 

- if MBMS SERVICE INFORMATION indicates that the service is on p-t-m: 
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- receive the MBMS RADIO BEARER INFORMATION and listen to the MTCH; 
else: 

- initiate request to setup the MBMS p-t-p RB; 

- if the UE receive the MBMS RADIO BEARER INFORMATION before the MBMS SERVICE 
INFORMATION and; 

- if MBMS RADIO BEARER INFORMATION contains the interested MBMS service id: 

- listen to the MTCH without the need of receiving the MBMS SERVICE INFORMATION. 

10.2.5 CELL_DCH State 

CELL_DCH state UE shall: 

act on the RRC message received on DCCH in handover, 
if the UE has the capability to support MBMS in CELL_DCH: 

if BCCH contains information regarding the MCCH in the new cell: 

- listen to the MCCH and receive the MBMS SERVICE INFORMATION; 

- if MBMS SERVICE INFORMATION contains the interested MBMS service id and; 

- if MBMS SERVICE INFORMATION indicates that the service is on p-t-m: 

- receive the MBMS RADIO BEARER INFORMATION and listen to the MTCH. 

- if the UE receive the MBMS RADIO BEARER INFORMATION before the MBMS SERVICE 
INFORMATION and; 

- if MBMS RADIO BEARER INFORMATION contains the interested MBMS service id: 

- listen to the MTCH without the need of receiving the MBMS SERVICE INFORMATION. 



1 1 Resource Management for MBMS 
11.1 MBMS Access Control Procedure 

MCCH messages initiating counting or recounting cause multiple responses from UEs within a cell. This may result in 
RACH congestion if number of UEs is high in a cell. To avoid this, CRNC may perform MBMS access control 
procedure during counting or recounting procedure. MBMS access control procedure is described in Figure 11.1. 



£75/ 



3GPP TS 25.346 version 6.10.0 Release 6 



52 



ETSI TS 125 346 V6.10.0 (2007-03) 



UEs 



2. Signaling tlie initial probability factor 



3. UE in Idle mode request 

RRC connection based on the 

initial probability factor 1 

UE in UFiA/CELL„PCH or 

CELL_FACH state response 

counting based on the initial 

probabilihr factor 2 



CRNC 



1. Setting of the initial 
probability factor 



4. Detecting the needs for 
updating 



5. Updating to the optimum 
probability factor 



6. Signaling the updated probability factor 



7. UE in Idle mode request RRC 

connection based on the updated 

probability factor 1 

UE in URA/CELL_PCH or CELL_FACH 

state response counting based on the 

updated probability factor 2 



Figure 11.1: MBMS Access Control Procedure 

1. CRNC calculates an initial probability factor for an MBMS service when a MCCH message causing counting or 
recounting is about to be sent. CRNC can use different probability factor for UEs in Idle mode and for different 
UEs in URA_PCH, CELL_PCH and CELL_FACH. 

2. CRNC includes the probability factor into the MCCH message and sends it to UEs. This can be done in MBMS 
Group Notification. 

3. UEs in idle mode or in URA_PCH, CELL_PCH and CELL_FACH state passing the probability check performs 
counting response UEs keep listening to MCCH to get updated probability factor until they have successfully 
responded to counting or counting is no longer required. 

4. CRNC detects the probability factor needs to be updated. Detecting mechanism is not to be standardized. 

5. CRNC recalculates the probability factor. The way of calculating new probability factor is not to be 
standardized. 

6. CRNC includes the updated probability factor into the MCCH message and sends it to UEs. 

7. UEs in idle mode or in URA_PCH, CELL_PCH or CELL_FACH state that pass the probability check, by using 
updated probability factor, perform counting response. 

CRNC and UEs that are still trying to perform the counting response repeat step 3 ~ step 7 until e.g. counting or 
recounting procedure ends. 
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1 1 .2 Frequency layer Convergence 



Frequency Layer Convergence denotes the process where the UTRAN requests UEs to preferentially re-select to the 
frequency layer on which the MBMS service is intended to be transmitted. This layer preference could be done by an 
additional MBMS session related Layer Convergence Information (LCI) such as offset and target frequency. The FLC 
is supported by specifications for both networks utilizing HCS and for networks not utilizing HCS. 

The preferred layer (PL) is indicated per MBMS service and the LCI (offset) is the same for all MBMS services on a 
given preferred layer. UTRAN can consist of multiple preferred layers and the PL for given services is decided by 
RRM. Thus the PL for an MBMS service might be different in different parts of the service area. Network co-ordination 
between RNCs may be added for the Rel-7. 

The LCI can be signalled to UEs by the CRNC after the session start is received over lu interface until reception of the 
session stop. The UEs shall take LCI into account whenever it is signalled on the MCCH in Idle mode and URA_PCH, 
CELL_PCH and in CELL_FACH states. The FLC is not applicable in CELL_DCH state, as it is only effecting UEs cell 
re-selection procedure. 

The UE shall ignore Sintersearch parameter only for the potential preferred layers when LCI is signalled and on 
preferred layer the UE shall apply the Sintersearch parameter. In case of UE is in CELL_FACH state without 
measurement occasions, the UE may not be able to measure cells on preferred layers. 

In the case that the UE has joined multiple services and they have different frequencies as preferred layer, the UE 
should apply the FLC applicable for the highest priority MBMS service, which it has activated and has a PL. The 
priority setting of different MBMS services is decided by NAS. 

Based on RRM decision, a given MBMS service can be provided on non-preferred layer by p-t-p or p-t-m transfer 
mode. 

The details of the mechanism are defined in state 3. 



1 1 .3 Frequency layer Dispersion 



Frequency Layer Dispersion (FLD) denotes the process where the UTRAN redistributes UEs across the frequencies. 
UTRAN can use FLD per MBMS session. 

The request to perform dispersion can be signalled to UEs by the CRNC after the session stop is received over lu 
interface. The UEs shall take into account this request whenever it is signalled on the MCCH. 

For FDD, the FLD is applicable in Idle mode, URA_PCH, CELL_PCH and CELL_FACH states. 

For TDD, the FLD is applicable in Idle mode, URA_PCH and CELL_PCH states. 

When FLC is applied, the UE stores the frequency where it was camped previously. Upon session stop, the UE attempts 
to return to that frequency. 

If the UE does not find a suitable cell on the target frequency, the UE attempts to select a cell on a randomly chosen 
frequency. 

Dispersion does not apply in the case where the UE decides to receive another service for which FLC is applied. 

The details of the mechanism are defined in the stage 3. 
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Annex A (informative): 
MBIVIS Phases in UTRAN 
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Figure A: Timeline of lUIBMS Service 

The UTRAN MBMS behavior is divided into 3 phases. Figure 14 illustrates the timeline of an MBMS service with 
regards to these phases. 



A1 Security for IVIBIVIS 



A cell stays in phase 1, if there is no ongoing session for the MBMS service, or if it does not belong to the MBMS 
service area of the service. 

A UE that has joined an MBMS service may regularly try to receive MBMS notification in a cell [FFS]. At this phase 
the UE does not request service delivery to UTRAN. 



A2 MBMS Phase 2 



This phase starts when UTRAN receives the MBMS "session start" from CN, and ends when UTRAN initially sets up 
MBMS radio bearer for the session, or decides not to set up the MBMS radio bearer in a cell. 
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In this phase, UTRAN transmits notification to UEs about the incoming service and could perform counting procedure 
to decide the type of MBMS radio bearer. UTRAN decides whether to set up p-t-m, p-t-p radio bearer or no radio 
bearer, based on the number of UEs that expected to receive the service in the cell. A UE that has at least one activated 
MBMS service acts on an RRC message in MCCH. 



A3 MBMS Phase 3 



This phase starts after initial MBMS radio bearer setup and ends when UTRAN receives the MBMS "session stop" 
from CN. 

In this phase, UTRAN transmits the data for the MBMS service received from CN using, if any, the established radio 
bearer. If there is no set-up radio bearer, UTRAN waits for service delivery request from UE. Recounting and radio 
bearer reconfiguration may be performed during this phase. 

UTRAN behaviour in this phase can be divided into three states: no transmission, p-t-p transmission, and p-t-m 
transmission. Each cell belonging to the same MBMS service area may be in any of three states. With the variation of 
the number of UEs, the state of a cell may change between the three states. UTRAN may broadcast the state of each 
cell. 

1 ) No Transmission: In this state of a cell, there is no established radio bearer because there is no UE who wants 
to receive the service. An MBMS-joined (or MBMS-interested in broadcast mode) UE in idle mode that moves 
into the cell of this state requests service delivery to UTRAN. 

2) P-t-p Transmission : In this state of a cell, p-t-p radio bearer is established. A UE that has joined (or interested 
in broadcast mode) an MBMS service may receive MBMS data over p-t-p radio bearer if there is MBMS data to 
receive. 

3) P-t-m Transmission: In this state of a cell, p-t-m radio bearer is established. A UE that has joined (or interested 
in broadcast mode) an MBMS service may receive MBMS data over p-t-m radio bearer if there is MBMS data to 
receive. 



A4 MBMS Phases and Status Parameters 

Table 1 lists the MBMS parameters that need to be broadcast in each MBMS phase. The list is [FFS] 

Table 1 : MBMS Status Parameters 





Phase 1 


Phase 2 


Phase 3 


Description 


Service ID 


X 


O 


O 


Identity of the Service 


Transmission 

State 


X 


X 


O (NONE/p-t-p/p-t-m) 


State of the cell for MBMS 
transmission 


Counting 


X 


O (On/Off) 


O (On/Off) 


Whether counting procedure is 
going on. 



1 ) Service ID: This parameters indicates is the identity of the service concerned. 

2) Transmission state: This parameter indicates to UE(s) the state of the concerned cell while it is in phase 3. 
According to this parameter, UE entering the cell starts re-configuration of the radio bearer, or requests service 
delivery to UTRAN. Specifically, if this parameter is set to "p-t-m", UE receives service over p-t-m radio bearer 
and if set to "p-t-p", UE receives service over p-t-p radio bearer. If it is set to NONE, UE has to request UTRAN 
to deliver the service. 

3) Counting: Tine counting parameter informs UEs whether counting is required (and is going on) or not. If this 
parameter is set to "ON", UE should perform RRC connection procedure. 
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Annex B (informative): 
MBIVIS Control Information 

Tables 2 and 3 describe MBMS control information in the downlink and uplink. 

Table 2: Mapping of MBMS Control Parameters in DL 



Information Element 


Description 


MICH - Transmitted continuously - Can be modified at a modification period boundary 


MBMS Notification 
Indicators 


Indicates when new information is to be transmitted on MCCH in the next modification period. 


BCCH - Transmitted periodically 


MCCH System 
Information 


Includes: 

- Configuration of the radio bearer carrying MCCH, 

- MCCH schedule information (access info, repetition and modification periods). 


MCCH - Non Critical Information - Transmitted at access info events - Can be modified at any transmission 


MBMS Access 
Information 


Contains parameters that control, for the purposes of counting, whether UEs should establish an 
RRC connection (idle mode) or make a cell update (URA_PCH state). It may include for each 
service for which counting is in progress: 

- MBMS service identity, 

- Probability factor (Idle mode), 

- Probability factor (URA_PCH), 

Additional parameters may be identified in stage 3. 


MCCH - Critical Information - Transmitted at repetition period Events - Can be modified at a modification 
period boundary 


MBMS Change 
Information 


Identifies MBMS services for which parameters are modified in this modification period. It 
may include for each service listed: 

- MBMS service identity, 

- MBMS session identity. 

Additional parameters may be identified in stage 3. In stage 3, MBMS Change Information is 
contained in the MBMS MODIFIED SERVICES INFORMATION message. 


MBMS Service 
Information 


Identifies MBMS services that are available in the cell. It may include for each service listed: 

- MBMS service identity, 

- MBMS session identity, 

- Indication that a p-t-m bearer is established for the service in the cell, 

- RB release indication, 

- Preferred frequency layer information. 

Additional parameters may be identified in stage 3. In stage 3, MBMS Services Information for 
a service is contained in either the MBMS MODIFIED SERVICES INFORMATION or the 
MBMS UNMODIFIED SERVICES INFORMATION messages depending upon the change 
status of the service. 


MBMS Radio Bearer 
Information 


Contains, for one or more MBMS services information describing the radio bearer and the p-t-m 
bearer that is used within the serving cell. It may include for each service listed: 

- MBMS service identity, 

- MBMS cell group identity, 

- Physical channel information, 

- Transport channel information, 

- Radio Bearer information. 

Additional parameters may be identified in stage 3. 
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MBMS Neighbouring 
Cell Information 


Contains, for one or more MBMS services transmitted in neighbour cells that can be used for 
soft or selective combining, information describing the p-t-m bearer to which it is mapped in the 
neighbour cell. It may include for each service listed: 

- MBMS service identity, 

- Cell identification information, 

- Physical channel information, 

- Transport channel information, 

- Radio Bearer information, 

- LI scheduling information, 

- Soft/ selective combining information. 
Additional parameters may be identified in stage 3. 


MSCH - Transmitted periodically 


MTCH Scheduling 
Information 


Contains information that enables UEs to perform discontinuous reception of MTCH. It may 
include for each of one or more services: 

- MBMS service identity, 

- The start time and duration of a period of data transmission, 

- Indication that there is no data transmission for one or more MSCH repetition periods. 



Table 3: Mapping of MBMS Control Parameters in UL 



Information Element 


Description 


DCCH - Service Related Control Information 


MBMS Joined Indication 


Indicates that a PMM IDLE state UE in RRC connected mode has joined at least one 
MBMS service 


MBMS P-T-P 
Modification Request 


UEs in CELL_DCH state may transmit this signalling flow to request the release of a p-t-p 
MBMS RB for a higher priority MBMS service. 
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Architecture) as an example (e.g. FACH). The "e.g." has 
now been deleted. 


1.6.0 


1.6.1 


06/03 


TSG 
RAN 
#20 








The version 2.0.0 identical to version 1 .6.1 was presented in TSG 
RAN plenary meeting for information and approval. The TS was not 
approved so drafting work will continue in WG2/3 based on version 
2.0.0. 

The changes in version 2.1 .0 compared to 2.0.0 are in Section 
5.1 .4 Counting where point 8 "The possibility for the RNC to 
receive the service Id in RRC connection request is [FFS]. . . " is 
removed. This reflects to the decision made in RAN2/3AdHoc 
05/03 but was missing from earlier versions, and pointed out by 
RAN WG2 chairman in reflector and in TSG RAN #20. 


2.0.0 


2.1.0 


09/03 


RAN2# 
37 

RAN3# 
37 


R2-031713 
R3-031174 
R3-031223 






Editorial corrections based on R2-031713 included. 

New chapter "7. MBMS reception UE Capability" crealed and 

agreed UE capability text inserted to the new chapter "7.1. UE 

Capability" . 

Modifications based on R3-031 1 74 to the definitions 

Sections 5.1.1, 5.1.5 and 5.1.6 enhanced and sections 5.1.7, 5.1.8 

and 5.1 .9 crated, and signalling flows updated in section 7.1 .based 


2.1.0 


2.2.0 
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on R3-031223 

Following Editorial enhancements proposed by editor: Chapter 
5.3.1.1 and 5.3.1.2 moved to under chapter 6.1. Logical channels 
and chapter "5.4 MBMS Reception in RRC States/Modes" moved 
under chapter 7. in new chapter "7.2 MBMS reception " 






10/03 


RAN2# 
38 

RAN3# 
38 


R2-032116 

R2-032074 
R2-032121 

R2-032277 

R2-032087 
R2-032275 
R2-032081 
R2-032281 

R3-031421 






Chapter 5.2. 1 MBMS User Plane Protocol Stack Architecture 

enhanced accordingly. 

Chapter 9 Security for MBMS enhanced accordingly 

Chapter 8.2.2 MBMS service availability enhanced, (message 

changed to information). Chapter 9.2. UE Actions for Mobility 

created and 9.2.4 text depending UE capability \nsene6 

Chapters 8.2.4. MBMS Joined Services Indication and 8.2.5 MBMS 

PMM-Connected State Required Indication created 

Chapters 6.1. re-formatted, Section 6.2.1-6.2.5 created 

The MBMS access control procedure inserted in chapter 11.1 

Broadcast of MBMS System Information signalling flow added. 

Tables inserted to an informative annex to identify MBMS control 

information and describe their mapping on transport channels 

MBMS Time line and MBMS Service announcement definitions 

included in Section 3.1 Chapter 5.1.1 One Context per MBMS 

Service in CRNC and 5. 1.8 RNC deregistration updated 

accordingly 

Editorial harmonization of terms: MCCH and MTCH used 

constantly. (NCCH and CTCH removed) 

In Uu signalling messages CRNC introduced to keep messages 

send/received in SRNC and CRNC inline. 


2.2.0 


2.3.0 


11/03 


RAN2# 
39 


R2-032350 
R2-032398 
R2-032667 

R2-032666 

R2-032497 






The Signalling flow MBMS service availability changed to MBMS 

service information in 8.2.2. Appropriate changes done in 10.2. 

In the Chapter 7.1. included that MBMS UE must capability to 

receive two SCCPCH 

MBMS notification principles chapter created as 5.1 .5 and RICH 

bits used for MBMS notification defined in 6.2.3 physical channels 

chapters. 

The number of different protocol entities clarified in chapter 5.2.1 . 

The shared PDCP entity principle created in 5.1.4. Protocol layerre- 

establishments due to mobility defined in 10.2. 

UEs measurements are clarified based in working assumption in 

Section 10.2. 

Editorial enhancements to chapter names in chapters 5.1 .1 , 5.1 .2 

and 5.1.3 


2.3.0 


2.4.0 


01/04 


RAN2# 
40 

RAN3# 
40 


R2-04086 

IVIeeting 
report 

R2-040027 
R2-040070 

R3-040061 
R3-040075 
R3-040076 






A chapter 1 1 .2 Frequency layer Convergence introduced based on 

revised text from R2-04086 

Text inserted based on conclusion on selective combining, 

multiplexing and measurement occasions 

Editorial clarifications. Constant usage of MBMS Service Area as 

defined in [4] 

Session stop included 

High level signalling scenarios inserted 

Modification to chapter 5.1 .8 
Modification to RNC registration procedure 
Additional modifications to 5.1.8 


2.4.0 


2.5.0 


02/04 


RAN2# 
41 

RAN3# 
41 


Meeting 
minutes 
R2-040572 

R2-040690 
R2-04071 1 

R3-040b// 
R3-040576 

R3-040314 
R3-040393 

R3-040575 
R3-040458 
R3-040516 






Selective combining, simulcast for TDD, Neighbouring cell info, 

included 

MCCH scheduling, MBMS notification and counting enhanced. 

MBMS access 

MTCH Scheduling information signalling flow included 

MBMS high level signalling scenarios updated 

Editorial clean up, separation of UTRAN architecture principles and 

MBMS Uu principles chapter created 

Functionality to filtering of MBMS notifications and Session update 

signalling flow included 

MBMS Service Id Request to handle UEs in RRC connected PMM 

idle state. The Signalling flow MBMS Joined Indication modified 

and MBMS PMM connected stated required removed. 

FFS removed from RNC De-Registration and CN De-Registration 

Clarifications to MBMS lu bearer and MBMS Session Start and 

Session Stop and CN De-Registration 

UE linking over lur modified according agreements 

Clarification to creation of MBMS Service context after receiving the 
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R3-040545 

IVIeeting 

minutes 






first UE linl<ing 

Editorial clean up to RAN3 specific sections. 

Tfie lub bearer mecfianisms defined. 

Editorial enhancements based on comments after email review on 
RAN 1/2/3 reflectors. 






03/2004 


RAN#2 
3 


RP-040079 






Upgrade towards Change Control (Release 6) and ETSI MCC 
clean-up. 


2.6.0 


6.0.0 


06/2004 


RP-24 


RP-040216 


001 




Updates based on the MBMS ad-hoc, Budapest, 20-22 April 2004 


6.0.0 


6.1.0 




RP-24 


RP-040216 


002 




Updates to TS25.346 from the RAN3#42 meeting in Montreal, 
Canada, 10-1 4 May 2004 


6.0.0 


6.1.0 


09/2004 


RP-25 


RP-040340 


003 




Introduction of MBMS Change Information and Removal of usage 
of the secondary notification indicators 


6.1.0 


6.2.0 




RP-25 


RP-040340 


004 




Clarifications to Frequency Layer Convergence and UE behaviour 
at return on Service 


6.1.0 


6.2.0 




RP-25 


RP-040340 


005 




lur Linking for URA_PCH UEs and MBMS Session Start Request 
corrections for TS25.346 from RAN3#43 


6.1.0 


6.2.0 


12/2004 


RP-26 


RP-040492 


006 


1 


Actions due to MBMS session repetition and MBMS service 
phohtisation 


6.2.0 


6.3.0 




RP-26 


RP-040492 


007 


1 


Introduction of MSCH and soft combining and other general 
corrections 


6.2.0 


6.3.0 




RP-26 


RP-040492 


008 




Corrections to UE Linking, Session Start and addition of URA 
Linking and Information Exchange procedure 


6.2.0 


6.3.0 




RP-26 


RP-040492 


009 




Update of Annex B 


6.2.0 


6.3.0 


03/2005 


RP-27 


RP-050080 


010 




Introduction of MBMS Frequency dispersion 


6.3.0 


6.4.0 




RP-27 


RP-050080 


Oil 




Correction on MBMS multiplexing and soft combining in TDD 


6.3.0 


6.4.0 




RP-27 


RP-050080 


012 




Clarification to UE capabilities to consider MCCH reception and 
selective/soft combining requirements 


6.3.0 


6.4.0 




RP-27 


RP-050080 


013 




Extending the counting procedure for UEs in CELL_PCH/FACH 
state and introducing UE initialised p-t-p setup request 


6.3.0 


6.4.0 




RP-27 


RP-050080 


015 




Introduction of new procedure in MBMS stage 2 spec 


6.3.0 


6.4.0 


06/2005 


RP-28 


RP-050314 


0016 




FLD scenario clarifications 


6.4.0 


6.5.0 




RP-28 


RP-050314 


0018 




Handling the validity of the MBMS session Id 


6.4.0 


6.5.0 


09/2005 


RP-29 


RP-050468 


0019 




Change of scope for the MBMS Access Information and MBMS P- 
T-P Modification Request signalling flows plus editorial corrections 


6.5.0 


6.6.0 


12/2005 


RP-30 


RP-050788 


0020 




Correction to MBMS Cell Group 


6.6.0 


6.7.0 


06/2006 


RP-32 


RP-060368 


0021 




Clarification of conditions for soft combining 


6.7.0 


6.8.0 


09/2006 


RP-33 


RP-060624 


0023 


1 


Enhancing MBMS support for Mobile TV 


6.8.0 


6.9.0 




- 






- 


Correction on date on coversheet - no technical change 


6.9.0 


6.9.1 


03/2007 


RP-35 


RP-070151 


0025 


1 


Modification of the MBMS Service Area definition 


6.9.1 


6.10.0 
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